WO2013188900A1

WO2013188900A1 - Validation of virtual entities of a multi-user application

Info

Publication number: WO2013188900A1
Application number: PCT/AU2012/001259
Authority: WO
Inventors: Geoff BATTYE
Original assignee: National Ict Australia Limited
Priority date: 2012-06-19
Filing date: 2012-10-17
Publication date: 2013-12-27

Abstract

This disclosure concerns computer-implemented methods and computer systems for validating virtual entities of a multi-user application on a network with multiple peers. State information of a virtual entity of a first peer is determined. A validator is selected for the virtual entity based on one or more selection criteria, wherein the validator is selected from (i) the first peer; (ii) a regular peer of the first peer; and (iii) a trusted peer of the first peer. The state information of the virtual entity is sent to both the first peer and the validator such that the first peer sends subsequent user inputs relating to the virtual entity to the validator, and the validator updates the state information of the virtual entity based on the user inputs and sends the updated state information to another peer on the network.

Description

Validation of Virtual Entities of a Multi-user Application Cross Reference to Related Application

The present application claims priority from Australian Provisional Application No. 2012902563 filed on 19 June 2012, the content of which is incorporated herein by reference.

Technical Field

This disclosure generally concerns multi-user applications, and in particular, computer- implemented methods, computer systems and computer programs for validating virtual entities of a multi-user application. This disclosure also concerns an application development platform for enabling a developer of a multi-user application to implement the methods. Background

One of the major concerns in multi-user applications such as online gaming is cheating. There are several ways in which users can attempt to cheat, and many of them involve locally running a version of the game which has been modified or hacked to give them an unfair advantage.

Summary

According to a first aspect, there is provided a computer-implemented method for validating virtual entities of a multi-user application on a network with multiple peers, the method comprising:

(a) determining state information of a virtual entity of a first peer;

(b) selecting a validator for the virtual entity based on one or more selection criteria, wherein the validator is selected from:

(i) the first peer;

(ii) a regular peer of the first peer; and

(iii) a trusted peer of the first peer; and

(c) sending the state information of the virtual entity to both the first peer and the validator such that the first peer sends subsequent user inputs relating to the virtual entity to the validator, and the validator updates the state information of the virtual entity based on the user inputs and sends the updated state information to another peer on the network. The method according to the first aspect provides a hybrid architecture that allows the trade-off between a high-cost secure system, and a low-cost less secure system to be dynamically adjusted. At one end of the spectrum, selecting the (iii) trusted peer as a validator is the most secure option, but causes scalability problems due to increased traffic and computational resource usage at the trusted peer. At the end of the spectrum, selecting the (i) first peer itself is the least costly option, but runs the risk of the user modifying the state information to gain unfair advantage. In between, selecting the (ii) regular peer as a validator balances the trade-offs by improving scalability while reducing the risk of the users manipulating the state information of their virtual entities. As such, the method provides greater flexibility to adjust the architecture of the multi-user application from client-server to peer-to-peer (P2P) based on one or more selection criteria in real time.

Further, it will be appreciated that a validator is selected for each virtual entity independently. The selected validator is responsible for validating the state information of the virtual entity, as opposed to managing all the virtual entities in a particular region within a virtual environment of the multi-user application. Advantageously, the method may be used in a distributed interest management system that determines which peers need to receive updates from a particular virtual entity. The distributed interest management system is responsible for providing relevant real-time information to all the virtual entities in the virtual environment and ensuring their state information is accurate and updated.

The one or more selection criteria may include a reputation value of the first peer; and the (ii) regular peer or (iii) trusted peer is selected if the reputation value is low, but < otherwise the (i) first peer is selected if the reputation value is high.

The one or more selection criteria may include one or more performance metrics of a network connection between the (i) first peer and (ii) regular peer; the (i) first peer and (iii) trusted peer; or the (iii) the trusted peer and a trusted authority.

The one or more selection criteria may include a load level at the trusted peer; and the (iii) trusted peer is selected if the load level at the trusted peer is low, but otherwise the (i) first peer or (ii) regular peer is selected if the load level at the trusted peer is high. The one or more selection criteria may include availability of the (ii) regular peer and (iii) trusted peer; and the (iii) trusted peer is selected if the regular peer is not available, the (ii) regular peer is selected if the trusted peer is not available, and the (i) first peer is selected if both the trusted peer and regular peer are not available.

The state information may include one or more of the following properties: position of the virtual entity within a scene provided by the multi-user application; a bounding area of the virtual entity, and an area of interest of the virtual entity. In this case, the one or more selection criteria may include a desired security level associated with one or more properties of the virtual entity; and the (ii) regular peer or (iii) trusted peer is selected if the desired security level is high, the (i) first peer is selected if the desired security level is low. The (ii) regular peer may be a peer with no virtual entity inside or near the area of interest of the virtual entity.

The method may further comprise digitally signing the state information of the virtual entity before sending it to both the first peer and the validator.

The method may further comprise assigning the virtual entity with a back-up validator that replaces the validator when the validator becomes unavailable.

The method may be performed by a trusted authority that controls the trusted peer.

According to a second aspect, there is provided a computer system for validating virtual entities of a multi-user application on a network with multiple peers, the computer system comprising a processor to:

(a) determine state information of the virtual entity of a first peer;

(b) select a validator for the virtual entity based on one or more selection criteria, wherein the validator is selected from:

(i) the first peer;

(ii) a regular peer of the first peer; and

(iii) a trusted peer of the first peer; and

(c) send the state information of the virtual entity to both the first peer and the validator such that the first peer sends subsequent user inputs relating to the virtual entity to the validator, and the validator updates the state information of the virtual entity based on the user inputs and sends the updated state information to another peer on the network.

According to a third aspect, there is provided a computer-implemented method for validating virtual entities of a multi-user application on a network with multiple peers, wherein the method is performed by a validator and comprises:

(a) the validator receiving, from a first peer, a user input relating to the virtual entity of the first peer, wherein the validator is selected from:

(i) the first peer;

(ii) a regular peer of the first peer; and

(iii) a trusted peer of the first peer; and

(b) the validator determining whether the user input is valid; and

(c) if the determination is affirmative, the validator updating state information of the virtual entity based on the user input and sending the updated state information to another peer on the network.

The updated state information may be sent to an interested peer having the virtual entity within an area of interest of a virtual entity controlled by the interested peer. The method according to the third aspect may further comprise periodically sending the updated state information to the user or a trusted authority, or both. The method may , also further comprise the validator digitally signing the updated state information before sending it. For example, in the event that the validator goes offline, the digitally signed state information may be sent to a new validator to facilitate validator migration. The new validator is . selected from the (i) first peer, (ii) regular peer and (iii) trusted peer according to the first aspect.

According to a fourth aspect, there is provided a computer system for validating virtual entities of a multi-user application on a network with multiple peers, wherein the computer system is associated with a validator and comprises:

a data store to store state information of one or more virtual entities;

a processor to:

(a) receive, from a first peer, a user input relating to a virtual entity of the first peer, wherein the validator selected from:

(i) the first peer;

(ii) a regular peer of the first peer; and (iii) a trusted peer of the first peer; and

(b) determine whether the user input is valid; and

(c) if the determination is affirmative, update state information of the virtual entity based on the user input and sending the updated state information to another peer on the network.

According to a fifth aspect, there is provided a computer program comprising computer-executable instructions to cause a computer system (acting as (i) the first peer, (ii) a regular peer of the first peer, and (iii) a trusted peer of the first peer) to implement the method according to the first aspect and/or the fourth aspect.

According to a sixth aspect, there is provided an application development platform for enabling a developer of a multi-user application to implement the method of the first aspect and/or fourth aspect.

Brief Description of Drawings

Non-limiting example(s) will now be described with reference to the accompanying drawings, in which:

Fig. 1 is a schematic diagram of an example computer network in which a multi-user application is implemented;

Fig. 2 is a schematic diagram of an example virtual environment in which virtual entities interact with each other;

Fig. 3 is a flowchart of an example method for validating virtual entities of a multi-user application; and

Fig. 4 is a schematic diagram of a computing device capable of acting as a validator, user, regular peer and trusted peer.

Detailed Description

Fig. 1 shows an example computer network 100 in which a multi-user application such as online gaming and virtual world is implemented. The network 100 includes multiple peers (also known as nodes or users) 110, 120, 130, 140 who participate in the multiuser application and communicate with each other, and a trusted authority 150, via a communications network 160. The trusted authority 150 may be implemented using a central server that is operated by a developer of the multi-user application. Any suitable network 160 may be used, such as a wide area network (WAN), local area network (LAN) and mobile communications network.

Throughout this disclosure, a "peer" (1 10, 120, 130, 140) on the network 160 generally refers to a computer system, an example of which includes:

a computing device (112, 122, 132, 142) which may be a game console, desktop computer, laptop computer, tablet computer, mobile phone, personal digital assistant (PDA), portable game player etc.;

a display device (114, 124, 134, 144) which may be a display screen or a television screen of the respective computing device (1 12, 122, 132, 142); and

a user input device (116, 126, 136, 146) which may include one or more keyboards, thumbsticks, buttons, triggers and D-pads (physical or simulated on the display device) to enter user inputs. Referring also to Fig. 2, an example virtual environment 200 provided by the multi-user application includes multiple virtual entities (A, C, D, E, G) each representing an object such as a player's avatar or collectible item. Each virtual entity (A, C, D, E, G) has a state defined by dynamic properties that change over time. The properties include a position in a space (two- or three dimensional) 210, a bounding area 220 defined by a radius, and an area of interest 230 defined by another radius. In this example, the bounding area 220 is smaller than the area of interest 230, but other configurations may be used depending on the application. Additional properties may be defined as required by its function in the multi-user application, such as orientation, colour, maximum velocity etc.

In. the example in Fig. 2, virtual entity A is instantiated and controlled by a peer 110, which is also referred to as an "originating peer", "first peer" or "local peer" of A. From the perspective of this particular peer 1 10, other virtual entities C, D, E and G are remote virtual entities that are each instantiated and controlled by a remote computer system or "remote peer". For example, virtual entities C, D and G are controlled by remote peers 120, 130, 140 in Fig. 1 respectively. Virtual entity E is controlled by the trusted authority 150, which is also known as a "trusted peer".

A scene is a virtual space in which virtual entities may exists. Every virtual entity must belong to a scene, and will, not receive updates from the other virtual entities that are not in the same scene. An application may have multiple scenes representing multiple levels, instances or shards etc. Virtual entities in a given scene will only be replicated to other peers if a virtual entity of the peer has joined the same scene. Scenes can be used to represent different levels in a game, or distinct parts of a virtual world, that cannot be 'seen' from each other.

For example, the originating peer 110 of virtual entity A is only interested in remote (replica) entities C and D whose bounding areas intersect with its area of interest 230. In this case, the originating peer 1 10 will receive updates for replica entities C and D, but will be unaware of E and G which are outside of area 230. As shown in Fig. 1 , original entity A and replica entities C and D are shown within a scene on the display 114 of peer 110.

Since virtual entity A is within the area of interest 240 of C, the remote peer 120 hosting C will receive state information updates for entity A, but not D, E and G. Similarly, remote peer 130 hosting entity D will only receive updates for entity A within D's area of interest 250, but not C, E and G. As shown in Fig. 1, virtual entities A and C are visible within a scene on the display 124 of the peer 120 controlling C, while virtual entities A and D are visible on the display 134 of the peer 130 controlling D.

Although the area of interest 230, 240, 250 has been exemplified using a sphere centred upon a position of a virtual entity A, C, D, it may be of any suitable shape. The shape and size of an area of interest may be adjusted for each entity type according to need. For example, a player character's area of interest should be at least as big as their view distance. A non-player character's area of interest could be smaller, if they are intended to ignore players who are not close to them.

Fig. 3 shows an example method for validating of virtual entities in the multi-user application. Distributed validation is supported, in which every virtual entity in the system 100 is assigned a validator that hosts the validated virtual entity.

Using this method in Fig. 3, validators can be changed dynamically anytime during a user session without any interruption to the multi-user application at the originating peer. The validator is generally assigned in steps 310 to 340 by the trusted authority 150, or depending on the application, one of the peers (1 10, 120, 130, 140). The steps in Fig. 3 will be explained with reference to the example in Fig. 2. At step 310 in Fig. 3, current state information of a virtual entity of one of the peers (e.g. A of peer 1 10) is determined. The state information includes dynamic properties of the virtual entity at a particular time, and may include the position of the virtual entity A, its bounding area 220, its area of interest 230, and optionally replica entities C and D in its area of interest 230, for example. In some implementations, the state information may include multiple application-specific dynamic properties.

At step 320, a validator for virtual entity A is selected from one of the following:

(i) the originating peer itself ("first peer" 110);

(ii) a regular peer (one of peers 120, 130, 140); and

(iii) a trusted peer controlled by the trusted authority 150. In general, selecting the originating peer as its own validator is least secure but is the most efficient in terms of conserving network traffic because it is not necessary to send state information updates to a remote peer. On the other hand, selecting a trusted peer is most secure but introduces additional traffic to the trusted authority 1 0. The regular peer of virtual entity A may be a disinterested peer (E and G) or ah interested peer (C and D).

In one extreme, all virtual entities are assigned to the trusted peer, in which case the system 100 operates like a client-server system. In another extreme, virtual entities could be assigned to their originating peers, in which case the system 100 operates like a naive peer-to-peer system. In between, the virtual entities could be assigned to their regular peers to improve scalability while reducing the risk of the originating peers manipulating the state information of their virtual entities.

Selection of the validator may be based on one or more of the following criteria:

(a) State information of the virtual entity

The selection may depend on current or historical state information of the virtual entity A, such as its position in a scene in the virtual environment 200 and a desired level of security associated with the position or scene. If virtual entity A is chatting and meeting other entities, for example, there is no incentive for cheating in this scene. In this case, option (i) is selected. On the other hand, if the virtual entity A is in a scene where virtual entities are trading virtual currency with each other, the more secure option (iii) is more suitable to prevent cheating.

For this example, the selection is based on a desired security level associated with the position of the virtual entity. The (iii) trusted peer is selected if the desired security level is high, the (ii) the regular peer is selected if the desired security level is medium, but otherwise the (i) originating peer is selected if the desired security level is low.

The state information of the virtual entity may also be used to identify the disinterested peers aiid or interested peers on the network 160. In example in Fig. 1 and Fig. 2, peers hosting virtual entities E and G are disinterested peers of originating peer 110 (hosting A) because E and G are not within A's area of interest. On the other hand, peers 120 and 130 hosting virtual entities C and D, respectively, are interested peers of originating peer 110 because C and D are within A's area of interest. To reduce the likelihood of cheating, a disinterested peer is generally preferred over an interested peer to play the role of a validator.

It will be appreciated that a disinterested peer does not necessarily have to have a virtual entity; but it should not have any virtual entity that are inside or near the area of interest of a virtual entity hosted by an originating peer. (b) Availability of regular or trusted peers

The selection may depend on the availability of the regular peer and trusted peer. For example, the (iii) trusted peer is selected if the regular peer is not available, and the (ii) regular peer is selected if the trusted peer is not available. If both the trusted peer and regular peer are not available, the (i) originating peer will be selected.

(c) Load on Trusted Authority 150

The validator selection may be based on the overall load on the server acting as the trusted authority 150. For example, the (iii) trusted peer is selected if the central processing unit (CPU) and/or bandwidth usage at the trusted authority

150 is low, but otherwise (i) the originating peer or (ii) regular peer is selected if the CPU and/or the bandwidth usage at the trusted authority 150 is high. I/O (Input/Output) load on the server acting as the trusted authority 150 may also be used to indicate the overall load.

(d) Network Performance

The selection may be based on one or more performance metrics for a network connection between: the (i) originating peer and any one of the (ii) regular peers; the (i) originating peer and (iii) the trusted peer; or the (iii) trusted peer and the trusted authority 150.

Examples of performance metrics include packet loss rate, round-trip time, bandwidth, packet retransmission rate, and jitter. In one implementation, each originating peer records a round trip time for every remote connection. The round trip time is used to estimate the latency of the connection in order to select one of the regular peers, or the trusted peer, as the validator. For example, if the originating peer has poor or unreliable connection with the regular peers, the trusted peer is selected as the validator. In another scenario, if the connection between the trusted peer and the trusted authority 150 is poor, a regular peer is selected.

(e) Reputation information of the originating peer

In a reputation-based scheme, the selection criteria may include a reputation value of the originating peer.

Individual applications may use different methods and parameters to compute the reputation value for a peer. For example, an application may use the time spent in a game to calculate the reputation value. For example, the longer a peer has spent in a game, the higher would be the reputation value for that peer.

An originating peer having a high reputation value (e.g. higher than an upper threshold) can be assigned as its own validator as they are less likely to cheat. On the other hand, an originating peer with a low reputation value (e.g. lower than a lower threshold) should be assigned a trusted peer for validation until their reputation value improves. The example method in Fig. 3 provides a hybrid architecture that combines client- server and decentralised architectures and facilitates development of highly scalable multi-user applications. A client-server architecture, which allows peers 110, 120, 130, 140 to communicate only with the trusted authority 150, often has scalability problems as the number of peers increases and the trusted authority 150 becomes a bottleneck. A peer-to-peer architecture offers a solution to these scalability problems by decentralising validation to the peers 1 10, 120, 130, 140, but run the risk of these peers cheating.

For example, in a multi-user online gaming application, allowing game logic to run on untrusted peers can allow those peers to manipulate game state contrary to the rules of the game to give an unfair advantage to or penalise certain players. The hybrid architecture offers protection against hacked clients by allowing game logic to run on arbitrary peers within the network, including regular and trusted peers.

Running a player's virtual entity on a peer that is not controlled by the player prevents the player from directly manipulate their own character's state information. Running on a disinterested peer further reduces motivation of the controller of that peer to try and manipulate game state. Running on a trusted peer is effectively like funning on the trusted authority 150, but with the added advantage of dynamically switching between client-server mode and peer-to-peer mode.

At step 330 in Fig. 3, once the validator is assigned, the current state information of the virtual entity is digitally signed so that it cannot be tampered with and will be recognised as valid state information.

At step 340 in Fig. 3, the state information of the virtual entity is sent to both the originating peer and validator. In the example in Fig. 2, virtual entity G is a disinterested peer that is selected as a validator for virtual entity A. In this case, the state information of virtual entity A is sent to the originating peer 110 that controls virtual entity A, and the remote peer 140 that controls virtual entity G.

Once the validator is assigned, the originating peer will send user inputs to the validator for validation. At step 350 in Fig. 3, the validator receives user input relating to virtual entity A entered by the originating peer via user input device 116. The user input might be in any suitable format, such as a byte array which is generally an efficient serialized user input representation. For example, the user input may be related to the movement or activity performed by virtual entity A.

At step 360 in Fig. 3, upon receiving the user input from the originating peer 110, the validator G determines whether the user input is valid, such as by checking whether the user input conforms to the rules and policies of the multi-user application. For example, in a multi-user game, the validator G will also ensure that the originating peer 110 is not sending any illegal input or sending input at a rate faster than allowed. The validator will also check if the originating peer has the permissions to use the specific input. For example in an online game, if pressing the "space bar" indicates jumping, the validator will ensure that the specific peer is allowed to jump, before processing the input.

At steps 370 and 372 in Fig. 3, if the validator detects any illegal user input, it may inform the trusted authority 150.

Otherwise, at step 374 in Fig. 3, the remote peer 140 controlling validator G updates the state information for the virtual entity A. The virtual entity's updated state information is a function of its current state information, the user input and the time interval for the update. For example, if the state information for an entity includes its position in the game, then depending on the input received (such as the up-arrow, down-arrow), the validator will compute the new position for its updated state information. At step 380 in Fig. 3, the remote peer 140 controlling the validator G may digitally sign the updated state information so that it cannot be tampered with and only secure game states are recorded.

At step 390 in Fig. 3, the updated state information is dispatched by the validator G to interested virtual entities within the area of interest of the virtual entity A. For the example in Fig. 2, the interested entities of virtual entity A (now validated) are C and D. The validated entity A's replicable state information includes all properties that are used to calculate state information updates. Periodically, the validator G sends the state information update for virtual entity A to the entity A itself and also to the trusted authority at the central server 150. Upon receiving this state information update, the originating peer 1 10 will make any corrections to its state information for virtual entity A.

This correction ensures that its state information is accurately synchronised with the rest of the peers in the network. Since there will be some delay between the user input being sent to the validator G and the originating peer 110 receiving the new state, a technique called client-side prediction is used to hide this latency.

Client-side prediction is a latency hiding technique in which the originating peer 1 10 will update the validated virtual entity A locally, and buffer input used for the state update. Upon receiving the state information update from the remote peer 140 operating the validator G, the originating peer will. restore the entity's A state to the validated state, and then reapply buffered input to correct its predicted state. In practice, the same method (and software code) is used to predict state updates on the originating peer and make authoritative updates on the validator. This is because the update needs to be calculated in the same way on the originating peer 110 and the remote peer 140 operating the validator G to stop the predicted state from deviating from the true state. One exception is when a validated entity A needs to react to a custom message. Custom messages sent from other peers will be received by the entity hosted on the validator. Since the originating peer 110 will not be aware of the message, it cannot take it into account, and its predicted state may not match the authoritative state calculated on the validator G. This error is automatically corrected the next time an update is received from the validator G.

The validator G removes A as a validated entity when it receives an unregistration request from the originating peer 110, or when the originating peer 110 is no longer active. Validator Migration

If a validator for a virtual entity goes offline, a new validator will be assigned. This is done in a seamless manner so that the interested entities do not lose any state updates of the virtual entity. Any short delay between the current validator going offline and a new one being assigned is hidden from the originating peer using client-side prediction, as explained above. Once a new validator is assigned, the trusted authority 150 will send the last received state information update from the previous validator G to the new validator (E for example). The state information is used by the new validator as a starting point and the local entity sends its subsequent user input from that point in time to the new validator.

Further optimisations may be performed to ensure that validator migration is handled in a smooth manner. For example, when a validator G is assigned to a given entity A, a back-up validator is also assigned. During the normal user session, the validator will exchange information with the backup validator E. This includes information such as list of interested entities and any entity specific information set by the developer of the multi-user application. This ensures that when there is a transition, the backup validator is ready with all the information that it needs to start processing the state updates with minimal disruption. Development Platform

An application development platform may be provided for enabling a developer of a multi-user application to implement the example method in Fig. 3. The development platform usually comprises of a library that can be dynamically linked to any other software program. The library has an interface with well-defined software methods that provide all the necessary functionality. ¹

Some examples of the software methods are as follows:

1. CreateValidatedEntity(): Delegate for creating validated entities on validators.

2. RemoveValidatedEntityQ: Delegate for removing validated entities on validators. ^

3. ValidatedEntity(): A class that implements the ValidatedEntity interface.

4. CreateUpdate(): A member function of ValidatedEntity that creates an update consisting of the state change since last update was created. Application developers can access all the functionality via this interface. The methods available via the interface would depend on the actual implementation.

Computing device 400

The above examples can be implemented by hardware, software or firmware or a combination thereof. Referring to Fig. 4, an example structure of a device 400 capable of acting as a computing device 1 12, 122, 132, 142 is shown. The example device 400 includes a processor 410, a data store or memory 420 and a network interface device 440 and input/output (I/O) interface devices 450 that communicate with each other via a bus 430. Information may be transmitted and received via the network interface device 440, which may include one or more logical or physical ports that connect the device 400 to another network device. The I/O interface devices interface with a user input device (116, 126, 136, 146) to receive user inputs and with a display device (114, 124, 134, 144) such as to display virtual scenes. For example, the various methods, processes and functional units described herein may be implemented by the processor 410. The term 'processor' is to be interpreted broadly to include a CPU, processing unit, ASIC, logic unit, or programmable gate array etc. The processes, methods and functional units may all be performed by a single processor 410 or split between several processors (not shown in Fig. 4 for simplicity); reference in this disclosure or the claims to a 'processor' should thus be interpreted to mean 'one or more processors'.

Although one network interface device 440 is shown in Fig. 4, processes performed by the network interface device 440 may be split between several network interface devices. As such, reference in this disclosure to a 'network interface device' should be interpreted to mean 'one or more network interface devices".

The processes, methods and functional units may be implemented as machine-readable instructions executable by one or more processors, hardware logic circuitry of the one or more processors or a combination thereof. In the example in Fig. 4, the machine- readable instructions 424 are stored in the memory 420. Further, state information of virtual entity or entities is stored in the memory 420 to facilitate validation of the virtual entity or entities. It will be appreciated that the state information may also be stored in a remote data store accessible by the processor 410.

Further, the processes, methods and functional units described in this disclosure may be implemented in the form of a computer program product. The computer program product is stored in a computer-readable storage medium and comprises a plurality of computer-readable instructions for making a device 400 implement the methods recited in the examples of the present disclosure. The figures are only illustrations of an example, wherein the units or procedure shown in the figures are not necessarily essential for implementing the present disclosure. Those skilled in the art will understand that the-units in the device in the example can be arranged in the device in the examples as described, or can be alternatively located in one or more devices different from that in the examples. The units in the examples described can be combined into one module or further divided into a plurality of sub- units.

Although the flowcharts described show a specific order of execution, the order of execution may differ from that which is depicted. For example, the order of execution of two or more blocks may be changed relative to the order shown. Also, two or more blocks shown in succession may be executed concurrently or with partial concurrence. All such variations are within the scope of the present disclosure. It will be appreciated that numerous variations and/or modifications may be made to the processes, methods and systems as shown in the examples without departing from the scope of the disclosure as broadly described. The examples are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

1. A computer-implemented method for validating virtual entities of a multi-user application on a network with multiple peers, the method comprising:

(a) determining state information of a virtual entity of a first peer;

(i) the first peer;

(ii) a regular peer of the first peer; and

(in) a trusted peer of the first peer; and

(c) sending the state information of the virtual entity to both the first peer and the validator such that the first peer sends subsequent user inputs relating to the virtual entity to the validator, and the validator updates the state information of the virtual entity based on the user inputs and sends the updated state information to another peer on the network.

2. The method of claim 1, wherein:

the one or more selection criteria include a reputation value of the first peer; and the (ii) regular peer or (iii) trusted peer is selected if the reputation value is low, but otherwise the (i) first peer is selected if the reputation value is high.

3. The method of claim 1 or 2, wherein:

the one or more selection criteria include one or more performance metrics of a network connection between the (i) first peer and (ii) regular peer; the (i) first peer and (iii) trusted peer; or the (iii) the trusted peer and a trusted authority.

4. The method of claim 1, 2 or 3, wherein:

the one or more selection criteria include a load level at the trusted peer; and the (iii) trusted peer is selected if the load level at the trusted peer is low, but otherwise the (i) first peer or (ii) regular peer is selected if the load level at the trusted peer is high.

5. The method of any one of claims 1 to 4, wherein:

the one or more selection criteria include availability of the (ii) regular peer and (iii) trusted peer; and the (iii) trusted peer is selected if the regular peer is not available, the (ii) regular peer is selected if the trusted peer is not available, and the (i) first peer is selected if both the trusted peer and regular peer are not available.

6. The method of any one of the preceding claims, wherein the state information includes one or more of the following properties: position of the virtual entity within a scene provided by the multi-user application; a bounding area of the virtual entity, and an area of interest of the virtual entity.

7. The method of claim 6, wherein:

the one or more selection criteria include a desired security level associated with one or more properties of the virtual entity; and

the (ii) regular peer or (iii) trusted peer is selected if the desired security level is high, the (i) first peer is selected if the desired security level is low.

8. The method of claim 6 or 7, wherein the (ii) regular peer is a peer with no virtual entity inside or near the area of interest of the virtual entity.

9. The method of any one of the preceding claims, further comprising digitally signing the state information of the virtual entity before sending it to both the first peer and the validator.

10. The method of any one of the preceding claims, further comprising assigning the virtual entity with a back-up validator that replaces the validator when the validator becomes unavailable.

11. The method of any one of the preceding claims, wherein the method is performed by a trusted authority that controls the trusted peer.

12. Computer program comprising computer-executable instructions to cause a computer system to implement the method of any one of claims 1 to 11.

13. A computer system for validating virtual entities of a multi-user application on a network with multiple peers, the computer system comprising a processor to:

(a) determine state information of the virtual entity of a first peer; (b) select a validator for the virtual entity based on one or more selection criteria, wherein the validator is selected from:

(i) the first peer;

(ii) a regular peer of the first peer; and

(iii) a trusted peer of the first peer; and

14. A computer-implemented method for validating virtual entities of a multi-user application on a network with multiple peers, wherein the method is performed by a validator and comprises:

(a) the validator receiving, from a first peer, a user input relating to the virtual entity of the first peer, wherein the validator selected from:

(i) the first peer;

(ii) a regular peer of the first peer; and

(iii) a trusted peer of the first peer; and

(b) the validator determining whether the user input is valid; and

15. The method of claim 14, wherein the updated state information is sent to an interested peer having the virtual entity within an area of interest of a virtual entity controlled by the interested peer.

16. The method of claim 14 or 15, further comprising periodically sending the updated state information to the first peer or a trusted authority, or both.

17. The method of claim 14, 15 or 16, further comprising the validator digitally signing the updated state information before sending it to the originating peer.

18. Computer program computer-executable instructions to cause a computer system to implement the method of any one of claims 14 to 17.

19. A computer system for validating a virtual entities of a multi-user application on a network with multiple peers, wherein the computer system is associated with a validator and comprises:

a data store to store state information of one or more virtual entities;

a processor to:

(i) the first peer;

* (ii) a regular peer of the first peer; and

(iii) a trusted peer of the first peer; and

(b) determine whether the user input is valid; and

20. An application development platform for enabling a developer of a multi-user application to implement the method of any one of claims 1 to 1 1 and 14 to 17.