WO2005065796A1

WO2005065796A1 - Method and system for providing a real-time, interactive game over a client-server network

Info

Publication number: WO2005065796A1
Application number: PCT/GB2003/005672
Authority: WO
Inventors: Benjamin Tufnell; Nicholas Gow; James Quinnell
Original assignee: Worksunit Ltd.
Priority date: 2003-12-30
Filing date: 2003-12-30
Publication date: 2005-07-21
Also published as: AU2003290348A1; GB2425966A; GB0612710D0

Abstract

A real-time, interactive, distributed game involves a server and multiple clients. The clients are connected to the server by one or more communications networks. Each client includes a skin having a multimedia player providing screen access on multiple data input keys for signalling corresponding game input events to update a game score for that client; and a real-time graphical display showing updated game scores for multiple different clients; in comparison with one another. The client further includes a client communications facility for transmitting game input events to the server and for receiving updated game scores from the server. The server includes a server communications facility for receiving game input events from the clients and for transmitting updated game scores to the clients. The server further includes a game controller for saving client game input events received from the clients into a database for maintaining a set of game scores for the clients. The game scores are updated in accordance with the game input events received from the clients.

Description

METHOD AND SYSTEM FOR PROVIDING A REAL-TIME, INTERACTIVE GAME OVER A CLIENT-SERVER NETWORK

Field of the Invention

The present invention relates to real-time, interactive, distributed games involving a server and multiple clients, particularly for use in a business motivation context.

Background of the Invention

Many businesses employ staff in an office environment, and optimising the performance of these staff is very important for the success of the business. This is particularly the case where the staff are involved in marketing and sales, since high productivity in this area feeds through directly onto the bottom line.

There are various strategies available for motivating staff. In some cases personnel may be sent on an adventure activity, such as sailing or climbing, in order to improve teamwork and leadership skills. However, such activities are relatively expensive, and it is difficult to be certain of the business benefits. They are also disruptive of normal business operations, and potentially of risk to staff health.

Another possibility is to arrange a seminar or other form of presentation in order to deliver a desired message to staff members. This can be difficult or time-consuming to arrange, especially if the workforce is widely distributed in geographical terms (potentially across different countries and/or time-zones). The effectiveness of such presentations is also variable - staff can switch off mentally if the material is not sufficiently interesting or relevant.

The use of modern technology can help to alleviate some of the above problems. For example, most office staff are now provided with individual desktop computers, and these are typically network-linked to the Internet, or perhaps to a company intranet. This then provides a mechanism to deliver training and motivational materials to staff at their normal workplace, even if widely dispersed, thereby minimising the impact on their usual business activities.

The use of computer networks however, does nothing to cure any underlying deficiencies in the presentation materials themselves. A significant problem here is that the technology is simply being employed as an additional delivery route. In other words, companies have generally retained traditional motivational strategies, which have then been exploited using new technology. No-one has turned this approach on its head, and considered at a more fundamental level how new technology can best be utilised to enhance staff motivation and productivity. Summary of the Invention

Accordingly, one embodiment of the present invention provides a system for supporting a real-time, interactive, distributed game involving a server and multiple clients. The clients are connected to the server by one or more communications networks. Each client includes a skin having a multimedia player for displaying multiple data input keys for signalling corresponding game input events to update a game score for that client and for displaying real updated game scores for multiple different clients in comparison with one another. The client further includes a client communications facility connected to the communications network for transmitting game input events to the server and for receiving updated game scores from the server. The server includes a server communications facility connected to the communications network for receiving game input events from the clients and for transmitting updated game scores to the clients. The server also includes a game controller for saving client game input events received from the clients into a database for maintaining a set of game scores for the clients. The game scores are updated in accordance with the game input events received from the clients.

Typically the client systems are based on standard desktop computers, while the network(s) may be implemented over the Internet, a local area network (LAN), a wide area network, etc. The multimedia player and the communications facility on the client may be provided as separate standalone pieces of software, or may be provided as part of or in conjunction with some other program(s), such as a browser. The various data input keys are typically presented as a set of on-screen buttons that are clicked with a cursor in order to activate, but could be implemented by any other appropriate user interface device (e.g. a selection menu). The game scores for the different clients are typically presented in some form of bar graph, but could be implemented by any suitable graphic (e.g. a number representing a current score, a line chart depicting the time history for each score, and so on).

The game is especially suited for business motivation purposes. In such an environment, game input events correspond to business activities, such as sales or marketing tasks, which it is desired to stimulate. The game scores are then derived from the game input events by weighting the game input events in relation to their business importance. For example, two possible events might be arranging a sales visit, and concluding a sale. The latter event would be awarded more points within the game, since it has a greater value to the business.

The game has many advantages as a business motivation tool. The game is based on a technology infrastructure that is generally already in place (e.g. desktop computers linked by a company intranet). The game can involve large numbers of staff, even if geographically separated, assuming that they have access to machines connected to the network. The game does not disrupt or distract from normal business activities, such as by removing staff from their standard workplace, but rather provides an additional level of incentive and stimulation as they perform their core sales and marketing tasks. The real-time feedback of game scores provides an interactive, competitive aspect that motivates staff to high levels of performance. Furthermore, such benefits are immediately and directly quantifiable (unlike many other business tools), by comparing performance during the game with normal performance when the game is not in progress. In a typical implementation, the clients are allocated into teams. The allocation usually reflects some business organisation of staff involved in the game. For example, staff might be assigned to teams on the basis of their geographical or office location, or perhaps based on the product set or customer accounts for which they are responsible. In these circumstances, the server maintains a game score for each of the teams, with these game scores being updated in accordance with game input events received from clients allocated to the respective teams. The game scores displayed on the client systems then represent the game scores for the various teams participating in the game. Note that the allocation of staff in this manner into teams can be used to stimulate cooperation and bonding between staff who need to work together within the business organisation. In one embodiment, the client skin is designed to reflect a theme such as a balloon flight, underwater exploration, and so on. Typically, the multimedia player further displays an animation to support this theme, which helps to maintain staff focus on the game. This animation is usually preinstalled onto the clients prior to commencement of the game, in order to preserve available network bandwidth during the game run itself. (The animation and other client software may be distributed prior to the game either over a network, or via some other route, such as by sending CDs to staff participating in the game).

In one implementation, the course of the animation is dependent upon game input events from a client and/or upon updated game scores received from the server. This then helps to provide an additional level of motivation and incentive for staff to perform well. For example, the animation may incorporate some form of barrier such as a door, which only opens in response to a client achieving a particular game input event, or once the team score for the client reaches a certain level.

It will be appreciated that providing an imaginative and stimulating animation increases staff involvement with the game. Nevertheless, there may be a tendency for such interest to wane after repeated runs of the game. One way to counter this is to change skins for different game runs, thereby helping to retain staff interest in the game by providing new and stimulating game environments.

In one embodiment, the multimedia player displays a message board on the clients. Typically this is used to display messages that are entered by an administrator at the server and transmitted over the communications network to the clients. These messages may represent instructions and commentary relating to the game, and offer the opportunity to provide additional motivation to staff participating in the game. The messages may be broadcast to all clients, or may potentially be targeted at individual clients or teams. Some implementations may also support messaging between clients, again potentially at an individual level, a team level, or a broadcast level. Generally such messages are routed from one client to another via the server, although other embodiments may support direct client-to-client messaging. In one embodiment, the database utilised by the server is located on the server itself. This provides for rapid access between the game controller and the database. Alternatively, the database may be provided on a separate system from the game controller. The database preferably maintains a complete record of the status of the game. This then allows the game to be restarted on some future occasion based on information in the database. Such a need might arise for example if a game has to be temporarily suspended due to network problems.

An important element of the game is that clients regularly receive updated reports of game status. This feedback supports the real-time competitive nature of the game. This in turn can place a heavy load onto the network(s) linking the clients to the server. Various strategies can be adopted to minimise this load. In one embodiment, when the server has updated a piece of information, such as by adding a game input event to the game score for the relevant team, the server broadcasts notification of the update to all clients participating in the game. Clients who want the update (because that piece of information is currently on active display at the client) then respond to the notification with a request for the update. The server duly obliges by transmitting the update to those clients that have specifically requested it. Although this procedure involves three messages (a notification from the server, a response from the client, and then the update itself from the server), it has nevertheless been found to be generally more efficient than the server automatically transmitting updates to all of the clients. The reason for this is that the notification and response are usually significantly smaller than the update itself, and typically only a relatively small proportion of clients are interested in receiving an update at any given time.

Another strategy to help reduce communications that is adopted in one embodiment is for the server communications facility to maintain a separate message queue for each client. A message can then be deleted from a message queue if it is superseded by or combined into a subsequent message in the same queue. (One possibility here is that the earlier message is overwritten by the subsequent message, modified if appropriate, so as not to delay sending). Such an approach helps to reduce the overall number of messages being sent out over the network, and is especially beneficial with respect to clients connected to the server by a relatively slow link (for whom a pending message queue is more likely to form at the server).

In accordance with another embodiment of the invention, there is provided a server for use in a real-time, interactive, distributed game. The game involves the server and multiple clients, with the clients being connected to the server by one or more communications networks. The server includes a communications facility connected to the communications network for receiving game input events from the clients and for transmitting updated game scores to the clients. The server also includes a game controller for saving client game input events received from the clients into a database, and for maintaining a set of game scores for the clients. The game scores are updated in accordance with the game input events received from the clients. In accordance with another embodiment of the invention, there is provided a client for use in a real-time, interactive, distributed game. The game involves a server and multiple clients, with the clients being connected to the server by one or more communications networks. A client includes a skin having a multimedia player for displaying multiple data input keys for signalling corresponding game input events to update a game score for that client. The multimedia player further displays real- time game scores for multiple different clients in comparison with one another. The client further includes a communications facility connected to the communications network for transmitting game input events to the server and for receiving updated game scores from the server, where the game scores are updated in accordance with the game input events received from the clients. Another embodiment of the invention provides a method of running a real-time, interactive, distributed game involving a server and multiple clients. The clients are connected to the server by one or more communications networks, and each client includes a skin having a multimedia player. The method comprises providing multiple data input keys at a client for signalling corresponding game input events, and transmitting the game input events from the client to the server over the communications networks. The game input events from the clients are then received at the server, and saved into a database for maintaining a set of game scores for the clients. The game scores for the clients are updated in accordance with the game input events received from the clients, with the updated game scores then being transmitted back to the clients from the server. The clients display updated game scores for multiple different clients in comparison with one another.

Another embodiment of the invention provides a method of operating a server to run a realtime, interactive, distributed game involving the server and multiple clients. The clients are connected to the server by one or more communications networks, and each client includes a skin having a multimedia player. The method involves receiving game input events from the clients at the server, and saving client game input events received from the clients into a database for maintaining a set of game scores for the clients. The game scores for the clients are updated in accordance with the game input events received from the clients. The updated game scores are then transmitted to the clients from the server to allow updated game scores for multiple different clients to be displayed in comparison with one another on a client.

Another embodiment of the invention provides a method of operating a client participating in a real-time, interactive, distributed game involving a server and multiple clients. The clients are connected to the server by one or more communications networks. Each client includes a skin having a multimedia player. The method involves providing multiple data input keys at a client for signalling corresponding game input events, and transmitting the game input events from the client to the server over the communications network. This then allows the received game input events to be saved into a database and a set of game scores updated therefrom at the server. The client now receives updated game scores from the server, and displays the updated game scores for multiple different clients in comparison with one another.

Another embodiment of the invention provides a method of running a real-time, interactive, distributed game involving a server and multiple clients. The clients are connected to the server by one or more communications networks, and each client includes a skin having a multimedia player. The method includes receiving game input events in respect of clients at the server, and saving the received game input events into a database for maintaining a set of game scores for the clients. The game scores for the clients are updated at the server in accordance with the received game input events. The server transmits the updated game scores to the clients, which display the updated game scores for multiple different clients in comparison with one another. Note that in this embodiment, game input events are not necessarily received from the clients themselves, but rather possibly from some other system, such as perhaps an order database. This allows the game to be integrated into an existing IT infrastructure of an organisation. For example, sales staff may record actions or events during the game into an operational database, in the same manner as for their normal day-to-day operations. Information about these events can then be extracted (or forwarded) from the operational database to the server for accumulation into the client or team scores, thereby allowing real-time feedback to the clients concerning the current status of the game.

Another embodiment of the invention provides a computer program product comprising program instructions on a media for running a real-time, interactive, distributed game on a system including a server and multiple clients. The clients are connected to the server by one or more communications networks, and each client includes a skin having a multimedia player. The instructions, when loaded mto the system, cause the system to provide multiple data input keys at a client for signalling corresponding game input events. These game input events are transmitted from the client to the server over the communications network. Client game input events received at the server from the clients are saved into a database. The server maintains a set of game scores for the clients, and these game scores for the clients are updated in accordance with the game input events received from the clients. The updated game scores are now transmitted back to the clients from the server, where the scores for multiple different clients are displayed in comparison with one another on a client.

In accordance with another embodiment of the invention, a computer program is provided for implementing the above methods. The program may be pre-installed into a system, or loaded off some portable storage medium, such as a magnetic tape, CD ROM, DVD, etc.. Alternatively, some or all of the program may be downloaded via a transmission medium over a network. It will be appreciated that the method and computer program product embodiments of the invention will generally benefit from the same particular features as the system embodiment of the invention, as described above.

Brief Description of the Drawings

Various embodiments of the invention will now be described in detail by way of example only with reference to the following drawings in which like reference numerals pertain to like elements and in which: Figure 1 is a schematic diagram of a client-server network configuration, which underlies one embodiment of the present invention; Figure 2 is a schematic diagram showing more detail of the client from the configuration of Figure 1 in accordance with one embodiment of the invention; Figure 3 is a schematic diagram showing more detail of the server from the configuration of Figure 1 in accordance with one embodiment of the invention; Figure 4 is a schematic diagram showing further details of the server from the configuration of

Figure 1 in accordance with one embodiment of the invention; Figure 5 is a flowchart showing the actions involved in initiating a game in accordance with one embodiment of the invention; Figure 6 is a flowchart showing the actions performed at the server during a game in accordance with one embodiment of the invention; Figure 7 is a schematic diagram showing more details of the buffer from the configuration of Figure 3 in accordance with one embodiment of the invention; and Figure 8 is a schematic diagram showing the user interface on a client system in accordance with one embodiment of the invention.

Detailed Description

Figure 1 is a schematic diagram of a distributed gaming system in accordance with one embodiment of the present invention. The game is implemented using a client-server architecture over network 100. Network 100 may represent any form of suitable wired or wireless communications facility, for example a local area network (LAN), a wide area network (WAN), or a combination of multiple individual networks. In addition, network 100 may be implemented in whole or in part over the Internet, a company intranet, or an extranet. One portion of the gaming system runs on server 110. In one embodiment, server 110 runs the Internet information server (IIS) program (version 5.0), which is built into the Windows NT server operating system available from Microsoft Corporation. In other embodiments, server 110 may not contain a formal server program such as IIS, and so could potentially be implemented on the same platform as a client 120. In this case, the server and clients would be distinguished by which portion of the gaming system they were running (as described in more detail below). The server 110 interacts over network 100 with multiple clients 120A, 120B, 120C, 120D and 120E. Typically, each client system 120 is associated with a sales or marketing employee who is participating in the game. Note that clients 120 may be distributed over a wide geographical area such as in different sales or branch offices. Consequently, clients 120 may be connected to server 110 by a variety of different network links (including potentially a set of multiple point-to-point links).

Individual clients 120 may be allocated into teams 130. Thus in the particular example shown in Figure 1, client 120A and client 120B are allocated to team A 130A, while client 120C, client 120D, and client 120E are allocated to team B 130B. The allocation of clients into teams typically reflects some structure within the organisation running the game. For example, a team might include all the personnel at one particular office, or all those working on one particular account. In many cases there is some geographical basis to the team allocations (e.g. everyone from one office belongs to the same team), but on other occasions members in the same team might in fact be geographically dispersed.

Although Figure 2 shows five clients participating in a game, it will be appreciated that in practice the number of people involved in a game may be very much larger than this. Thus one current implementation of server 110 supports games involving up to 1500 clients, which may be arranged in up to 100 different teams. Larger or smaller configurations may also be provided as appropriate.

Figure 2 illustrates the structure of client 120 in more detail in accordance with one particular embodiment of the invention. Typically client 120 is a desktop computer running the Microsoft Windows family of operating systems (e.g. Windows XP). However, other clients 120 may run different software, such as the Linux operating system, or represent different computer platforms, such as a Mac system available from Apple Corporation. Note that clients 120A, 120B, 120C, 120D and 120E need not all represent the same form of system, providing that they can all communicate as required with server 110.

Installed on client 120 is a skin 135. Server 110 supports multiple different game versions, where each game version has its own skin. All clients involved in a game have the relevant skin installed on their machine in order to participate in the game. Included within skin 135 is an executable 140 for playing or displaying any animation, graphics, and so on used in the game. In one embodiment, the executable 140 is the Flash program (version 6) available from Macromedia, Inc. Further details about the Flash program can be obtained from the site www.macromedia.com.

Note that a version of the Flash program is also available as a browser plug-in, e.g. for the Microsoft Internet explorer program. Accordingly, in some embodiments, the animation player executable may be replaced by a browser with a suitable plug-in. One advantage of using a browser in this manner for client 120 is that setting up the client is simpler, since many desktop computers already include a browser with a suitable Flash plug-in. However, in this case the general performance of the game may not be so good, due in part to the more complicated program structure and overheads associated with operating via a browser.

The skin 135 includes a game facility 150, which is shown in Figure 2 as being split into two portions 125A, 125B by line 151. Portion 152A of game facility 150 is generally common to multiple different skins 135, while portion 152B is generally dependent upon the particular skin installed on client 120.

The skin independent portion 152A of game facility 150 includes a communication subsystem 155. The communication subsystem 155 is responsible for interacting with network 100 in order to transmit data to server 110 and to receive data from server 110. In one embodiment, such communications are performed using extensible mark-up language (XML) over a TCP/IP link. Note that the Flash program (version 6.0) 140 provides support for such a TCP/IP link, and so in this particular embodiment the communications subsystem 155 interacts with network 100 via the player executable 140. In other embodiments, the communications may be channelled through a browser, or any other suitable program.

Figure 3 is a schematic diagram of server 110 in accordance with one embodiment of the invention. The server 110 includes a game engine 305 that interacts with the Internet information server previously mentioned (the IIS is not specifically shown in Figure 3). The game engine incorporates various components, including a communications server 310 for interacting with clients 120 over network 100, and a buffer 320, which is used by the communications server 310 to queue outgoing transmissions to clients 120. The game engine further includes a logic component 330, which is at the heart of game control operations. The logic component 330 is responsible for processing data received over network 100 from clients 120, and for updating the state of the game in accordance with this received data. Logic 330 is also responsible for providing clients 120 with information about the current status of the game. Associated with logic 330 is a parser (not shown in Figure 3) whose role will be described in more detail below.

Server 110 also includes a database 160, which in one embodiment is implemented using an Access database from Microsoft Corporation. Database 360 is used by logic 330 to store all relevant information about a game. This includes, amongst other things, the identities of all the clients 120 involved in the game, the teams 130 to which the various clients have been allocated, as well as the current performance of the participants. This information can be regarded as forming a game file 380 stored within database 160. The game file contains sufficient information to allow a game to be stopped and then restarted at some future time. This may be useful for example if a game is to be run over two or more days, since it allows the game to be suspended overnight. In addition, it also allows server 110 to restore a game to its previous state in the event of a network failure 100. In other words, if network 100 fails, the state of the game at the time of the failure will be stored in game file 380 in database 360. When network 100 is back up again, the information in game file 380 then allows the game to be resumed at the point immediately prior to network failure.

Note that in some cases there may only be a partial network failure, i.e. only certain clients, such as those in team A, namely client 120A and 120B (see Figure 1), are disconnected from the game. In this situation, when the network connection is restored, these clients can resume from their previous status (although it will be appreciated that the overall status of the game will have moved on due to continued interactions with clients whose network connections have not been interrupted).

As shown in Figure 3, database 160 may hold multiple games files 380A, 380B, representing games that have previously been played. Note that these various game files may include previous runs of the same game, i.e. all using the same skin 135, as well as runs of other games using different skins 135. In one implementation, each game file 380 is held as a separate database file.

Game engine 305 further includes a scripting engine 340, which can be used to interact with external database 385. Note that database 385 may in some implementations be hosted on server 110

(i.e. on the same machine as game engine 305), but more typically it is located on a separate machine, which may potentially be geographically remote from server 110. External database 385 may also be implemented by multiple databases (potentially at different locations).

Database 385 represents an operational database for the organisation running the game, such as an order database, a finance database, etc. In some implementations, it may be desirable for information from clients 120 entered during the course of the game to be captured into database 385. For example, during the course of the game, a client may indicate that a particular product has been ordered. This information needs not only to be recorded in database 360 as part of the game history, but also into database 385 (which in this instance may represent the order database for a company) in order for the organisation to subsequently fulfil the reported order. In this context therefore, scripting engine 340 receives details from logic 330, for example concerning the receipt of a particular order, and writes the relevant information into external database 385.

In other embodiments, clients 120 may communicate directly with external database 385 (i.e. not through server 110). In this case, logic 330 can extract information from database 385 in order to update the status of the game. Thus in this configuration, the clients do not directly report order information to server 110, but rather into database 385. This information is then extracted through scripting engine 340 into logic 330 so that it can be included in the game history. A hybrid implementation is also possible, for example where clients 120 write information into external database 385, but also send a notification of the update to game engine 305. This notification may include a token or identifier that allows the game engine to extract the new information from database 385. The skilled person will be aware of various implementations for scripting engine 340, which are typically dependent upon the type of external database 385 and the operations to be performed with it. For example, in some cases database 385 may automatically forward any relevant database updates to scripting engine 340, which can then pass the updates onto logic 330. Alternatively, database 385 may simply notify scripting engine 340 of (relevant) updates, and this notification then triggers the scripting engine 340 to retrieve the updates from database 385. Another possibility is that scripting engine interrogates database 385 on a regular basis to find out update information. One mechanism for doing this is for scripting engine 340 to monitor a log file of updates to database 385 to determine whether there is any new or modified information that should be uploaded to logic 330.

Game engine 305 further includes a reporting facility 345, which provides a mechanism for an administrator to access a game file 380 within database 360. The reporting facility 345 can therefore be used by the game administrator to monitor activity within the current game, such as to see the performance of the various teams and various clients. This can be useful for providing a real time assessment of the success of the game as well as for providing some form of commentary and/or encouragement to the participants, as will be described in more detail below.

The reporting facility 345 can also access game files for previous games, as well as information held in external database(s) 385. This permits a wide-ranging analysis of various data, both during and after a game. For example, the performance of one particular team or individual might be tracked through various games, in order to assess the overall impact of the games. Likewise, the results of games played at different times or on different days might be compared, to see if a given timing for the game is particularly productive. The game engine 305 further includes a game file interface 348. This is used to provide logic

330 and reporting facility 345 with a standardised facility for accessing the information in games files 380 within database 360.

Figure 4 illustrates certain components of server 110 in more detail in accordance with one particular embodiment of the invention, in particular those components involved in communications to and from server 110 over network 100. For these communications, the gaming engine 305 uses a Windows Socket control API to provide access to a TCP/IP protocol stack 410. (Note that the Windows Socket API and the TCP/IP protocol stack 410 are typically provided as part of the operating system running on server 110).

Communications server 310 establishes socket connections over network 100 to the various clients. Each socket connection 440 is associated with a client object 430A, 430B, 430C provided as part of the communications server 310 of the gaming engine 305. There is one client object on server 110 for each client participating in the game (the socket connection from client 430B in Figure 4 is omitted to improve clarity). Connection 440 provides a two-way communications facility between a client object 430 and its corresponding client 120. Server 110 uses the socket connection 440 to provide information about the game status to a client 120, while client 120 uses the socket connection 440 for transmitting data updates as well as any status requests back to server 110. Although only three client object are shown in Figure 4, the total number of clients (and hence client objects in server 110) may be much greater than this. For example, one embodiment of server 110 supports one thousand or more clients. If a very large number of clients are involved in a game, the volume of communications into and out of server 110 can be very significant. Care must therefore be taken to ensure that the network interconnection between the server 110 and the network 100 does not become a bottleneck on overall game performance. Thus in one particular implementation (based on having approximately 1000 clients), it is recommended that the network bandwidth close to server 110 has a capacity of at least 100 Mbits per second in order to accommodate the various data flows during a game. (The desired bandwidth for any given game may be more or less than the above figure, depending on the number of clients involved, the particular data flows generated by any given game, and so on. If the available bandwidth is on the low side, then in general the game can still be played, but will run more slowly). Stored within each client object 430 is some data 435A, 435B, 435C that is specific to the client associated with that client object. Note that this data 435 is a subset of the data that is stored within database 360, which as previously described provides a general repository for client information. The data 435 within a client object 430 duplicates part of database 360 in order to provide more rapid access to the relevant information than can be achieved from database 360. In particular, data 435 typically comprises information such as client identities, network addresses and so on, which the client object 435 uses on a frequent basis for interacting with client 120.

If a particular connection 440 goes down during the course of the game, then the corresponding client object 430A is terminated and its corresponding data 435 deleted. However, data about the client is maintained in the relevant game file 380 within database 360. Consequently, if network availability is subsequently restored, then a new object for that client can be (re)created using data from database 360.

Client objects 430 are mainly involved with handling the messaging aspects of communications with clients 120 rather than processing or generating the data involved in such communications. Instead, this is primarily the responsibility of the logic component 330. In particular, incoming communications from clients 120 are passed by the respective client object 430 through to a parser 450 within logic 330. The parser 450 is responsible for extracting data from the communication, such as an indication that a particular button on a client 120 has been pressed. The parser 450 then make this information available to the other components within logic 330 for further updating the game status and for storage in database 360.

Figure 5 illustrates a procedure for initially setting up a game in accordance with one embodiment of the present invention. The method begins with a game administrator launching the game program on server 110 (step 510). The administrator now decides whether it is desired to initiate a new game or to continue with an existing game (step 520). In the latter case the administrator selects from database 360 the existing game to be continued (step 525). On the other hand, if the administrator wants to initiate a new game, the administrator enters details of the various clients to be involved in the game, providing their names, network addresses, and so on (step 530). Note that in some embodiments, this information may be imported from a suitable directory or organisational database. The administrator also allocates the various clients involved in the game into one or more teams (step 530). (The allocation to teams is optional; some or all of the clients may participate in a game on an individual basis if so desired).

The administrator now selects the skin 135 to be used with this particular game (step 540). In one embodiment, this is performed by the administrator launching a game client with the desired skin on the server itself 110. This (local) client then contacts the server using a network connection 440 such as previously discussed (which can be formed within a single machine). The client skin 135 informs the server in generic terms of the mformation it needs to support the user interface of the skin. For example, the skin might indicate that it has four different user input buttons, a title bar, and so on. The server can then set up the game in conformity with the specified skin requirements. In this embodiment therefore, the skin 135 to be used in any given game is determined by a client first logging into the game server 110 and downloading to the server details of its own skin. It will be appreciated that this provides a flexible and readily extensible mechanism for allowing the server to support a variety of skins. For example, the server is potentially able to support new skins developed in the future, providing they conform to the same general pattern of user interface requirements.

It will be appreciated that other approaches to skin selection are possible. For example, some servers may support only a single predetermined skin, in which case there is clearly no need for skin selection during game initiation. Another possibility is that skin selection may be determined by the server, for example by the administrator specifying directly into the server the particular skin to be used with a game.

Once the skin to be used for the game has been selected, the administrator now supplies various game specific mformation (step 550). This information typically represents details such as text strings to be written into the various user interface buttons and the title bar of the selected skin. This defines the user interface to be used for the game (as experienced at client 120).

The administrator now enters various control parameters for the game (step 560). Some of these control parameters determine the internal logical implementation of the game. Thus the administrator can define the scoring to be awarded in relation to various client actions, such as particular buttons being pressed. This is used to adjust the parameters of the game to match the underlying business environment and requirements. For example, if button A is pressed to indicate the sale of a particular high value product (say product A), while button B is pressed to indicate the sale of a relatively low value product B, then the administrator will typically award more points for pressing button A than for pressing button B. In this way, the configuration of the game can be brought into line with business objectives, such as maximising overall sales revenue. At this stage the game administrator also enters various scheduling parameters for the game, such as the start time and the stop time. It will be appreciated that this sort of information may also be added by the administrator for a new run of an existing game (to the extent that such information has not aheady been provided, or is to be different in the new run from in the preceding run).

The game is now commenced (step 570). Note that this action allows clients to log into the game, rather than starting the active game run (which is controlled by the schedule information previously provided by the administrator). Accordingly, clients who join the game are held in effect at a waiting screen until the game run itself begins at the scheduled start time

In one embodiment, clients who log into a game must have the appropriate skin as defined for the game (at step 540). In other embodiments however, the server may support the use of different skins within a single game, although this may impact overall compatibility. For example, one skin might have buttons A, B and C, while another skin might have buttons A and B. In this situation, clients with the latter skin cannot notify server 110 of the operation corresponding to button C. (This may in fact reflect the underlying business situation, in that different staff may be permitted or targeted to perform somewhat different operations).

Figure 6 illustrates the general form of processing performed by server 110 during the operation of a game. The progress of a game is primarily driven by receipt of messages from the various clients 120 (step 610). These incoming messages can be broadly divided into two different types, namely a request for data from the server, or the supply of data to the server. Accordmgly, the game engine 305 processes the incoming message to determine which type of message has been received (step 620).

The former possibility (a request by the client for data from the server) typically occurs because the client is displaying a screen that indicates some current status of the game, such as the sales performance of certain teams. The client therefore requests from the server the underlying data for this display. The client request may be triggered by the user opening a particular window or screen to display the relevant information, in which case data is needed from the server to allow the relevant window to be populated. Alternatively, the client request may be triggered by a server notification (described in more detail below) that some status information relating to the game has been updated. , In either event, the server responds to the request from the client by providing the client with the desired information (step 630).

On the other hand, if the incoming message provides (rather than requests) a data update, then the received data update from the client is processed by logic 330 and parser 350 (step 630). This involves extracting the information from the incoming client message and performing any necessary processing of the incoming data to allow it to be used in the game. For example, the incoming data may indicate that the client has pressed a particular button. As previously described, this button may correspond to a certain number of points or score increment for the game. Accordingly, logic 330 updates the game in line with the client input, such as by determining the number of points to be awarded to a certain team in response to receiving notification from a client that a particular button has been pressed. The status of the game is then updated accordingly, which includes saving the new information into database 360 (step 640).

Once the game update has been applied, the server 110 notifies clients of the change in status (step 650). In one particular implementation, this is achieved by the server sending an alert message to all of the clients identifying the type of update applied. Those clients that are interested in this particular update, typically because it corresponds to data currently being displayed on the screen of the client 120, then respond to the notification by transmitting a request for the updated data to server 110. This request is then duly received and satisfied by server 110 as previously described in relation to steps 610 and 630.

One reason for this approach is to limit communications between the server and the client, in order to preserve bandwidth over network 100. Thus a data update from the server 110 to a client 120 may be quite sizeable in comparison with the simple alert message. Consequently, it is generally more efficient to send an alert message to every client followed by the data to a selected subset of clients (i.e. those clients that specifically respond back requesting the data), than to automatically distribute the data to every single client. In other words, the fact that typically many clients do not request any given data update compensates for the server having to send out two messages to some clients (the alert message followed by the data itself).

Nevertheless, it will be appreciated that a range of strategies may be employed in other embodiments for providing the clients 120 with updated information about the status of the game. For example, one possibility would be for clients 120 to poll the server 110 on a regular basis (e.g. perhaps every few seconds or once a minute) for updated mformation about the status of the game. Another possibility would be for the server to broadcast updated information to all clients, either as and when it is generated (as a result of data inputs from the clients), or perhaps at regular time intervals (perhaps every few seconds in order to give the game a good real-time impression). It will be appreciated that the best strategy for promulgating updates from server 110 to clients 120 will depend upon the particular circumstances of any given game and implementation, such as available network type and bandwidth, the number and type of client systems, the frequency of updates, and so on.

As previously discussed, clients 120 are typically connected to server 110 by a heterogeneous range of networks and communications links. Some of these links may be rather slower than others. This can lead to certain queues building up with respect to messages being sent to clients over these slower communication links.

Figure 7 illustrates a strategy employed in one embodiment of the present invention for mitigating such network problems. Outgoing communications from server 110 to be transmitted over network 100 are maintained in individual queues 710A, 710B, 710C, 710D, 710E in buffer 320. Each client 120 is assigned its own queue 710. (The number of separate queues maintained in buffer 320 is therefore in practice likely to be much greater than shown in Figure 7).

Figure 7 illustrates in more detail the structure of queue 710E for client E. (The other queues 710 in buffer 320 have a similar structure, but for clarity this detail is omitted from Figure 7). Queue 710E is implemented as a first-in-first-out (FIFO) queue 715, which is shown (for the sake of example) as currently having seven entries, 720A, 720B, 720C, 720D, 720E, 720F and 720G. These entries 720 are to be read out from FIFO queue 715 in the direction indicated by the arrow. In other words, the updates are to be transmitted in the order of 720G first, then 720F, then 720E, and so on. Each update is assigned a label, El, B2, Dl, etc. It is assumed that the alphabetical portion of this label determines the nature of the data, while the numerical portion reflects a sequence number. For example, there may be five teams in the game, denoted A, B, C, D, E, with a message 720 providing an update for the current performance of a particular team as indicated by the label for that message. Thus update 720F labelled Bl provides an update about the performance of team B, update 720D labelled CI provides an update about the performance of team C, and so on.

For certain labels (teams) there is more than one update in queue 710. For example, message 720G (label Al) reflects the status for team A at one point in time, while message 720E (label A2) contains a later update for the same team. If updates are presented in absolute (rather than relative) terms, then an update can be regarded as redundant if a subsequent update is aheady waiting in the queue behind it. Thus, there is relatively little to be gained from transmitting update 720G in Figure 7, given that update 720E will be transmitted shortly afterwards anyway to provide client E with the updated status of team A. In other cases, the relationship between successive messages may be different from simple overwriting. For example, in one embodiment, scores may be transmitted in relative terms (i.e. relative to the existing score), such as a sequence of +3, -6, +2, +6. In this case, the four separate update messages can be aggregated and replaced by a single update message, namely +5.

In other situations, there may be little scope for eliminating message content. Nevertheless, combining content from multiple messages into a single message can still help to improve communications efficiency (by reducing overheads). For example, messages from the server to clients may contain instructions from the game administrator (as described below). Instructions from different messages could potentially be combined into a single message containing all the instructions in order to reduce the number of messages being transmitted.

In one embodiment therefore, the entries 720 in outgoing queue 715 are monitored. Any messages that relate to the same category of information and that can be combined, aggregated or deleted in some fashion, such as just described, are detected. This then allows one or more messages to be deleted from the queue in favour of a single message.

The exact manner in which this is done depends on the inter-relationship between the various messages. For example, in the situation depicted in Figure 7, and assuming absolute (i.e. overwrite) updates, this can lead to the deletion of update 720G labelled Al in favour of update 720E labelled A2, and also the deletion of update 720F labelled Bl in favour of update 720B labelled B2. This helps to reduce the total number of updates being sent out from buffer 320, and so helps to optimise use of available bandwidth out of server 110 and onto network 100. Another possible approach to reduce queue size is to run on a regular basis a routine that scans each queue looking for two or more entries in respect of the same item. These entries can then be processed as appropriate. For example, with absolute updates, the earlier entries in the queue might be deleted, possibly by overwriting an earlier entry with a later entry. In Figure 7, this would involve overwriting entry 720G (labelled Al) with entry 720E (labelled A2). This has the advantage of ensuring that the deletion of queue entries does not delay information concerning a particular item (e.g. team) from being transmitted from server 110. Similarly, if information is being aggregated from multiple queue entries, then again this may potentially end up being stored in the earliest of the multiple queue entries, so as not to delay transmission. (Note that such processing generally requires the queue implementation to support these somewhat more complex operations).

Looking for earlier entries for the same item can also be performed whenever a new entry is added to the queue, with deletions, aggregations, etc then being performed accordingly. With this approach, there would not be two entries for the same item in a queue 715, since the earlier one would be deleted (or augmented) as the new one was being added. This helps to reduce the size needed for queue 715. Note that while Figure 7 illustrates the queues 710 of outgoing messages from server 110 to clients 120, there are may be other message or update queues within server 110. In particular, there is generally a queue of updates received from clients 120 that are waiting to be processed and added into database 360. There may also be a queue of updates to be transmitted (or received from) external database 385. The queue reduction facilities described with reference to Figure 7 can also be applied to these other queues, although in such circumstances the queues themselves will normally have a different location within server 110 (i.e. not within buffer 320, but typically within game file interface 348, for example, for updates pending entry into database 360).

Figure 8 depicts in high-level form a client screen in accordance with one embodiment of the present invention. The screen displays four different components, namely an animation viewer 820, a score panel 830, a message board 840 and a score pad 850. Client 120 may also display certain other information not shown in Figure 8, such as the name of the client, the team to which the client belongs, the current ranking of the team relative to other teams, the date and time, the amount of time remaining in the game, and so on.

The detailed appearance of the client screen is determined by the particular skin 135 selected for the game. Thus each skin 135 is typically based on a theme, such as a mission to outer space, or performing a deep-sea exploration dive. The layout and visual impression of the user interface on client 120 is then designed to reflect such a theme. For example, with a deep-sea exploration theme, the score panel 830, the message board 840, and the score pad 850 can be arranged to look like instrumentation panels at a submarine control position. The animation 820 can then be regarded as the view of the waters outside the submarine. Likewise, for a space mission theme, the user interface can mimic a control panel for a spaceship (as familiar from science fiction TV programmes and films).

The use of skins in this manner allows the games to be kept fresh and stimulating for staff across multiple game runs. Thus one skin can be utilised for one run, while another skin might be utilised for another run. This then helps to maintain high levels of interest and motivation for the games. Note that one possibility is to develop a particular customised skin for a given organisation.

For example, if a game is being hosted by a car sales firm, then a skin might be provided to mimic a car dashboard, with the animation viewer then portraying a view through the car windscreen.

Message board 840 is used to display messages for client 120. Typically these messages are generated by an administrator at server 110 and broadcast to all clients participating in the game. The messages might be used for example to provide a commentary on the game, or perhaps further instructions relating to the game itself.

Different implementations may support different levels of messaging during the game. For example, the administrator at server 110 may be able to direct messages to a particular client or to a particular group of clients (e.g. everyone in a certain team). This can then be used to provide targeted motivation, exhortation and so on. A further possibility is to allow messaging between clients (possibly just to other clients in the same team). In one implementation, any client-to-client messaging is routed initially to server 110, and then forwarded by server 110 to the target client(s). This allows the game administrator at server 110 to maintain an oversight of client-to-client messages. It will be appreciated that if the number of clients participating in a game is very large, then client-to-client messaging may be inhibited or disabled in order to reduce bandwidth requirements and to reduce clutter. Score panel 830 is used to provide an indication of the current scores of the various teams. In the example shown in Figure 8, it is assumed that there are three teams, A, B, C. The current score of each team is indicated by a bar 835A, 835B, 835C, with the length of the bar being indicative of the score of the respective team. Thus in the particular example shown in Figure 8, team B is leading, team A is second, and team C is third. The bars 835 are updated on a regular basis using information obtained from server 110 as previously described. The various scores may be presented within the score panel 830 in a fixed order (e.g. alphabetically by team name, as in Figure 8), or possibly in a dynamic order (e.g. according to current score ranking). It will be appreciated that any appropriate graphic can be used instead of (or as well as) a bar 835 in order to indicate the relative team scores. For example, score panel 830 may simply display a number representing the current team scores or perhaps a fixed block which changes colour in accordance with the team score.

In some circumstances, the number of teams (or clients) may be too large to display comfortably within panel 830. One option here is to allow a user to scroll within the score panel 830 between the scores for different teams. Note that in this case the client only needs to obtain updated game scores in respect of those teams currently visible in the score panel 830. (The client would therefore respond to the notification of step 650, see Figure 6, accordingly).

Score pad 850 is used by the user of client 120 for entering events into the game. In the particular example illustrated in Figure 8, score pad 850 comprises three different buttons 855A, 855B, and 855C, although other embodiments (and other skins) may have a different number of buttons. A user clicks on a button to indicate that a particular event has occurred or action has been performed. During the game therefore as staff perform their various tasks, perhaps over the telephone, they press (click on) an appropriate button 855A, 855B, 855C whenever they have completed the corresponding action. This event is then passed by client 120 back to server 110 so that the game status and the client or team score can be updated accordingly.

Buttons 855 are typically labelled with the different actions to which they correspond. For example button 855A may represent arranging to send a prospect some marketing literature; button 855B may represent arranging an appointment for a sales person to visit a prospect; and button 855C may represent a confirmed sale. Another possibility is that the buttons 855 all represent confirmed sales, but with different buttons being assigned to different sale values (or perhaps customer sets). The number of buttons in score pad 850 would then match the desired granularity of the sales breakdown.

Animation viewer 820 displays an animation or moving set of graphics, the main purpose of which is to provide visual interest and stimulation for a user at client 120. The animation reflects the theme of the skin. For example, if the skin relates to underwater exploration, then the animation can include passing fishes, sunken wrecks, and so on.

The course of the animation may be predetermined, or it may be sensitive to external factors. One possibility is that current performance of the client or team containing the client influences the course of the animation. For example, if a team reaches a particular level or score, it may be directed into a new region of sea to explore, or it may find some different forms of underwater animal appearing in the animation. There may also be some interactivity between the client and the animation. For example, the client may be permitted to explore the sea world by use of appropriate cursor keys or other suitable control inputs to direct motion within the world. Providing such a facility to control the animation helps to maintain interest in the game (although it should not distract users from the underlying purpose of the game, which is to increase sales, and such-like).

The animation for viewer 820 is typically incorporated into graphics 165 (see Figure 2) and pre-installed onto client 120 as part of the game-set-up. This avoids having to download the graphics over network 100 during the game itself, and so preserves network bandwidth for the more important real-time information relating to the game (events and scores).

Although Figure 8 illustrates the simultaneous display of score panel 830, score pad 850, message pad 840 and animation player 820, this is not necessarily the case for all skins. For example, in one skin a single display instrument (within the context of the skin theme) may be assigned to depict more than one of the items shown in Figure 8, such as both the message board 840 and also score panel 830. With this arrangement, a user of client 120 can typically control the instrument to determine whether it currently displays message board 840 or score panel 830. Consequently, the client 120 only needs to receive updated scores from the server when the user has selected to display the score panel 830. Another possibility is for score panel 830, message board 840 and so on to represent independent windows. The user can then be allowed to separately re-size, re-position, and minimise these windows as desired.

It has been found that the game approach described herein is highly effective at motivating staff and enhancing sales and other business performance. In order to achieve such benefits, it is important to make the game interesting and stimulating. This can be accomplished by using an imaginative and intriguing skin 135, which is then able to integrate both sales events (through score pad 850) and also team status (through score panel 830) into the context of the game. In addition, the animation presented by viewer 820 is helpful for supporting the theme of the skin.

Another significant aspect is the real-time feedback of client (typically team) status, thereby allowing participants to see how they or their team is currently performing in comparison with the other teams in the game. This in turn stimulates a sense of belonging and cooperation within teams, as staff provide each other with mutual support for their team to work towards a common shared goal (i.e. leadership of the game). The game also fosters competition between the different teams. This competitive aspect between the participating teams engenders a high sense of motivation and commitment of individual staff members to complete sales or other targeted activities for the benefit of their team (i.e. for gaining game points), in order to help their team outperform other teams in the game. This competitive element can be further encouraged by providing some prize or other form of recognition to the winning team(s).

Another important benefit of the approach described herein is that it can typically be implemented on top of existing infrastructure. Thus staff in many organisations aheady have suitable client systems connected by a network. In addition, a suitable server may aheady be available. This helps to minimise the costs for a customer of running a game.

A significant aspect of the game is that the motivational stimulus is delivered to staff in situ, integrated mto normal operational behaviour. This avoids any disruption that might be caused by removing staff from their normal work environment to participate in some other form of motivational activity. In addition, it is ensured that the stimulus is directly channelled into (i.e. aligned with) the main work roles of the relevant staff. In other words, staff do not accidentally get motivated to take actions (such as tidying desks) that are of only marginal benefit to the business.

Another benefit of the in situ nature of the game is that the benefits of the game are directly and quantitatively measurable. For example, sales volumes (or other performance measures) during the course of a game can be readily compared with sales volumes during equivalent periods when no game is running. Consequently it is possible to ascertain the positive impact of the game in relation to the bottom line (e.g. in terms of increased sales). In conclusion, a variety of particular embodiments have been described in detail herein, but it will be appreciated that this is by way of exemplification only. The skilled person will be aware of many further potential modifications and adaptations that fall within the scope of the claimed invention and its equivalents.

Claims

1. A system for supporting a real-time, interactive, distributed game involving a server and multiple clients, said clients being connected to the server by one or more communications networks; each client including a skin having a multimedia player for displaying (i) multiple data input keys for signalling corresponding game input events to update a game score for that client; and (ii) realtime updated game scores for multiple different clients in comparison with one another, said client further including a client communications facility connected to said one or more communications networks for transmitting game input events to the server and for receiving updated game scores from the server; and said server including a server communications facility connected to said one or more communications networks for receiving game input events from the clients and for transmitting updated game scores to the clients, and a game controller for saving client game input events received from the clients into a database for maintaining a set of game scores for the clients, wherein said game scores are updated in accordance with the game input events received from the clients.

2. The system of claim 1, wherein said clients are allocated into teams, and wherein the server maintains a game score for each of said teams.

3. The system of claim 2, wherein the game score for a team is updated in accordance with game input events received from clients allocated into that team.

4. The system of claim 2 or 3, wherein said real-time updated game scores are for said teams.

5. The system of any preceding claim, wherein said multimedia player further displays an animation.

6. The system of claim 5, wherein said animation is preinstalled onto a client prior to commencement of the game.

7. The system of claim 5 or 6, wherein the course of said animation is dependent upon game input events from that client.

8. The system of any of claims 5 to 7, wherein the course of said animation is dependent upon updated game scores received from the server.

9. The system of any preceding claim, wherein said multimedia player further displays a message board.

10. The system of claim 9, wherein messages for display on the message board may be entered by an administrator at the server and transmitted over the one or more communications networks to at least one of said clients.

11. The system of any preceding claim, wherein said database is located on said server.

12. The system of any preceding claim, wherein said database maintains a record of the status of the game, thereby allowing the game to be restarted on some future occasion based on information in the database.

13. The system of any preceding claim, wherein having updated the game scores in accordance with a game input event received from a client, the server broadcasts notification of the update to all clients participating in the game.

14. The system of claim 13, wherein the server transmits updated an game score to those clients that respond to said notification with a request for the updated game score.

15. The system of any preceding claim, wherein the server communications facility maintains a separate message queue for each client.

16. The system of claim 15, wherein a message is deleted from a message queue if it is superseded by or combined into a subsequent message in the queue.

17. The system of any preceding claim, wherein said game is used for business motivation purposes.

18. The system of claim 17, wherein said game input events correspond to sales or marketing actions, and the game scores are derived from the game input events by weighting the game input events in relation to their business importance.

19. The system of claim 17 or 18, wherein said clients are allocated into teams, said teams reflecting an office organisation of a sales or marketing group.

20. A server for use in a real-time, interactive, distributed game involving the server and multiple clients, said clients being connected to the server by one or more communications networks, said server including a server communications facility connected to said one or more communications networks for receiving game input events from the clients and for transmitting updated game scores to the clients, and a game controller for saving client game input events received from the clients into a database for maintaining a set of game scores for the clients, wherein said game scores are updated in accordance with the game input events received from the clients.

21. A client for use in a real-time, interactive, distributed game involving a server and multiple clients, said clients being connected to the server by one or more communications networks, said client including a skin having a multimedia player for displaying (i) multiple data input keys for signalling corresponding game input events to update a game score for that client; and (ii) real-time updated game scores for multiple different clients in comparison with one another, said client further including a client communications facility connected to said one or more communications networks for transmitting game input events to the server and for receiving updated game scores from the server, wherein said game scores are updated in accordance with the game input events received from the clients.

22. A method of running a real-time, interactive, distributed game involving a server and multiple clients, said clients being connected to the server by one or more communications networks, and each client including a skin having a multimedia player, said method comprising: providing multiple data input keys at a client for signalling corresponding game input events; transmitting the game input events from the client to the server over said one or more communications networks; receiving game input events from the clients at the server; saving client game input events received from the clients into a database for maintaining a set of game scores for the clients, and updating game scores for the clients in accordance with the game input events received from the clients; transmitting updated game scores to the clients from the server; and displaying updated game scores for multiple different clients in comparison with one another on a client.

23. The method of claim 22, wherein said clients are allocated into teams, and wherein the server maintains a game score for each of said teams.

24. The method of claim 23, wherein the game score for a team is updated in accordance with game input events received from clients allocated into that team.

25. The method of claim 23 or 24, wherein displaying updated scores comprises displayed updated game scores for said teams.

26. The method of any of claims 22 to 25, further comprising displaying an animation on the client.

27. The method of claim 26, wherein said animation is preinstalled onto a client prior to commencement of the game.

28. The method of claim 26 or 27, wherein the course of said animation is dependent upon game input events from that client.

29. The method of any of claims 26 to 28, wherein the course of said animation is dependent upon updated game scores received from the server.

30. The method of any of claims 22 to 29, further comprising providing a message board at the clients.

31. The method of claim 30, further comprising entering by an administrator at the server a message for display on the message board, and transmitting the message over the one or more communications networks to at least one of said clients.

32. The method of any of claims 22 to 31, wherein said database is located on said server.

33. The method of any of claims 22 to 32, further comprising said database maintaining a record of the status of the game, thereby allowing the game to be restarted on some future occasion based on information in the database.

34. The method of any of claims 22 to 33, further comprising the server broadcasting notification of the updated game scores to all clients participating in the game.

35. The method of claim 34, further comprising selected clients responding to said notification with a request for an updated game score, and said server transmitting the updated game score to said selected clients.

36. The method of any of claims 22 to 35, further comprising maintaining a separate message queue for each client at the server.

37. The method of claim 36, further comprising deleting a message from a message queue if it is superseded by or combined into a subsequent message in the queue.

38. The method of any of claims 22 to 37, wherein said game is used for business motivation purposes.

39. The method of claim 38, wherein said game input events correspond to sales or marketing actions, and the game scores are derived from the game input events by weighting the game input events in relation to their business importance.

40. The method of claim 38 or 39, wherein said clients are allocated into teams, said teams reflecting an office organisation of a sales or marketing group.

41. A method of operating a server to run a real-time, interactive, distributed game involving said server and multiple clients, said clients being connected to the server by one or more communications networks, and each client including a skin having a multimedia player, said method comprising: receiving game input events from the clients at the server; saving game input events received from the clients into a database for maintaining a set of game scores for the clients, and updating game scores for the clients in accordance with the game input events received from the clients; and transmitting updated game scores to the clients from the server to allow updated game scores for multiple different clients to be displayed in comparison with one another on a client.

42. A method of operating a client participating in a real-time, interactive, distributed game involving a server and multiple clients, said client being connected to the server by one or more communications networks, and including a skin having a multimedia player, said method comprising: providing multiple data input keys at a client for signalling corresponding game input events; transmitting the game input events from the client to the server over said one or more communications networks, to allow the received game input events to be saved into a database and a set of game scores updated therefrom at the server; receiving updated game scores from the server; and displaying updated game scores for multiple different clients in comparison with one another on the client.

43. A method of running a real-time, interactive, distributed game involving a server and multiple clients, said clients being connected to the server by one or more communications networks, and each client including a skin having a multimedia player, said method comprising: receiving game input events in respect of clients at the server; saving the received game input events into a database for maintaining a set of game scores for the clients, and updating game scores for the clients in accordance with the received game input events; transmitting updated game scores to the clients from the server; and displaying updated game scores for multiple different clients in comparison with one another on a client.

44. A computer program product comprising program instructions on a media for running a realtime, interactive, distributed game on a system including a server and multiple clients, said clients being connected to the server by one or more communications networks, and each client including a skin having a multimedia player, said instructions, when loaded into the system, causing the system to perform the steps of: providing multiple data input keys at a client for signalling corresponding game input events; transmitting the game input events from the client to the server over said one or more communications networks; receiving game input events from the clients at the server; saving client game input events received from the clients into a database for maintaining a set of game scores for the clients, and updating game scores for the clients in accordance with the game input events received from the clients; transmitting updated game scores to the clients from the server; and displaying updated game scores for multiple different clients in comparison with one another on a client.

45. A computer program product comprising program instructions on a media for running a realtime, interactive, distributed game on a system including a server and multiple clients, said clients bemg connected to the server by one or more communications networks, and each client including a skin having a multimedia player, said instructions, when loaded into the server, causing the server to perform the steps of: receiving game input events from the clients at the server; saving client game input events received from the clients into a database for maintaining a set of game scores for the clients, and updating game scores for the clients in accordance with the game input events received from the clients; and transmitting updated game scores to the clients from the server to allow updated game scores for multiple different clients to be displayed in comparison with one another on a client.

46. A computer program product comprising program instructions on a media for running a realtime, interactive, distributed game on a system including a server and multiple clients, said clients being connected to the server by one or more communications networks, and each client including a skin having a multimedia player, said instructions, when loaded into one of said clients, causing the client to perform the steps of: providing multiple data input keys at the client for signalling corresponding game input events; transmitting the game input events from the client to the server over said one or more communications networks, to allow the received game input events to be saved into a database and a set of game scores updated therefrom at the server; receiving updated game scores from the server; and displaying updated game scores for multiple different clients in comparison with one another on the client.

47. A system for running a real-time, interactive, distributed game involving a server and multiple clients, said clients being connected to the server by one or more communications networks, and each client including a skin having a multimedia player, said system comprising: means for providing multiple data input keys at a client for signalling corresponding game input events; means for transmitting the game input events from the client to the server over said one or more communications networks; means for receiving game input events from the clients at the server; means for saving client game input events received from the clients into a database for maintaining a set of game scores for the clients, and updating game scores for the clients in accordance with the game input events received from the clients; means for transmitting updated game scores to the clients from the server; and means for displaying updated game scores for multiple different clients in comparison with one another on a client.

48. A computer program for implementing the method of any of claims 22 to 43.