Methods and systems for generating and managing active objects in video games

Abstract

A method of managing evolution of an active object in a game space based on interaction of one or more players with the active object, the method including the following steps implemented concurrently and independently by server-side and client-side modules: acquiring data indicative of a first player's interaction with the active object during gameplay; determining data indicative of a first state of the active object and data indicative of a first attribute associated with the first state; determining altered state data indicative of a second state of the active object, wherein a second attribute is associated with the second state; and determining evolved object data indicative of a change from the first attribute to the second attribute. Further, the client-side module uses the evolved object data to render the active object on the first player's client device in the second state and the second attribute.

Description

FIELD

The present specification is related generally to the field of video games and graphics processing. More specifically the present specification is related to efficiently managing transition of states and attributes of active objects during a gaming session of a multiplayer video game.

BACKGROUND

Active objects are game assets with which a player can interact during gameplay. Active objects have one or more associated states that may change based on the progress of the game. As an active object's state transitions, the object's behavioral, visual and/or functional characteristics may change.

As video games become increasingly complex and large scale, game levels and worlds have evolved to include an increasing number of active objects. This increase requires a corresponding increase in a gaming platform's computational and data storage requirements.

Accordingly, there is a need for systems and methods that improve the tracking, updating, and transitioning of active objects' states and attributes and the managing of such states and attributes between a game server and client devices. There is also a need for reducing the amount of data exchanged between the game server and the client devices pertaining to active object states and attributes as a result of players' interactions with the active objects. Finally, there is a need for generating and managing the states and attributes of active objects such that a rich and data-dense amount of information can be used to characterize an active object while not unduly overburdening the processing and/or bandwidth requirements of executing the video game.

SUMMARY

The following embodiments and aspects thereof are described and illustrated in conjunction with systems, tools and methods, which are meant to be exemplary and illustrative, not limiting in scope. The present application discloses numerous embodiments.

In some embodiments, the present specification discloses a method of managing a scriptable object in a game space of a multi-player video game based on interactions of a player with the scriptable object via a client-side device, wherein the multi-player video game is hosted by at least one server, wherein the at least one server is configured to execute a server-side module and wherein the client-side device is configured to execute a client-side module, the method comprising: acquiring, by the server-side module and by the client-side module, data indicative of the player's interaction with the scriptable object during a game session of the multi-player video game, wherein the scriptable object comprises a first portion tracked by the server-side module and a second portion tracked by the client-side module; determining, by the server-side module, data indicative of an initial state of the first portion and, by the client-side module, data indicative of an initial state of the second portion; determining, by the server-side module, first altered state data indicative of a next state of the first portion and, by the client-side module, second altered state data indicative of a next state of the second portion; determining, by the server-side module, first evolved object data of the first portion and, by the client-side module, second evolved object data of the second portion; and rendering, by the client-side module, an updated scriptable object based on the first evolved object data and the second evolved object data.

Optionally, the initial state of the first portion has an associated first initial attribute and the next state of the first portion has an associated first next attribute, and wherein the initial state of the second portion has an associated second initial attribute and the next state of the second portion has an associated second next attribute.

Optionally, the evolved object data of the first portion is indicative of a change from the first initial attribute to the first next attribute of the first portion, and wherein the evolved object data of the second portion is indicative of a change from the second initial attribute to the second next attribute of the second portion.

Optionally, the altered state data of the first portion and the altered state data of the second portion is determined based on the player's interaction with the scriptable object.

Optionally, rendering of the second portion is performed if the player's location is determined, by the client-side module, to be proximal to a location of the scriptable object in the game space.

Optionally, rendering of the first portion is performed if the server-side module sends the altered state data of the first portion to the client-side module.

Optionally, the evolved object data of the first portion and the evolved object data of the second portion are representative of an evolution of at least one of a behavioral, visual or functional characteristic of the scriptable object.

In some embodiments, the present specification discloses a method of managing a change in an active object in a game space of a multi-player video game based on an interaction of a player with the active object, wherein the multi-player video game is hosted by at least one server and is configured to be at least partially executed on a client device controlled by the player, wherein the at least one server executes is configured to execute a server-side module, and wherein the client device is configured to execute a client-side module, the method comprising: acquiring, by the server-side module, data indicative of the player's interaction with the active object during a gameplay session of the multi-player video game; determining, by the server-side module, data indicative of a first state of the active object and data indicative of a first attribute associated with the first state; determining, by the server-side module, altered state data indicative of a second state of the active object, wherein a second attribute is associated with the second state; sending, by the server-side module, said altered state data to the player's client device; determining, concurrently and independently by both the server-side module and the client-side module, evolved object data indicative of a change from the first attribute to the second attribute; and rendering, by the client-side module, the active object in the second state and the second attribute using said evolved object data.

Optionally, the active object has associated therewith a plurality of states that are owned by the server-side module, and wherein each of said plurality of states has associated at least one attribute.

Optionally, the active object contains data indicative of the first state and the second state along with data defining the first attribute and the second attribute, and wherein execution of said programmatic instructions determines said evolved object data.

Optionally, the altered state data is determined based on the player's interaction with the active object.

Optionally, the evolved object data is representative of an evolution of at least one of a behavioral, visual or functional characteristic of the active object.

Optionally, the method further comprises sending, by the server-side module, the altered state data to a client-side module of a client device controlled by a second player; determining, by the client-side module on the second player's client device, said evolved object data; and rendering, by the client-side module on the second player's client device, the active object on the second player's client device using said evolved object data.

Optionally, a location of a virtual character controlled by the second player is proximal to a location of the active object within the game space.

In some embodiments, the present specification discloses a method of managing an evolution of an active object in a game space of a multi-player video game based on interactions of one or more players with the active object, said one or more players using respective client devices to be in data communication with at least one server that implements the game space on each of the client devices, wherein the at least one server executes a server-side module and each of the client devices executes a client-side module, the method comprising: acquiring, by a client-side module configured to execute on one or more client devices controlled by the one or more players, data indicative of one of the one or more players' interaction with the active object during gameplay; determining, by the client-side module, data indicative of a first state of the active object and data indicative of a first attribute associated with the first state; determining, by the client-side module, altered state data indicative of a second state of the active object, wherein a second attribute is associated with the second state; determining, by the client-side module independent of the server-side module, evolved object data indicative of a change from the first attribute to the second attribute; and using said evolved object data, by the client-side module, to render the active object on the client device in the second state and the second attribute.

Optionally, the client-side module renders the active object only if the one of the one or more players is located proximal to the active object in the game space.

Optionally, the active object contains data indicative of the first state and the second state along with data defining the first attribute and the second attribute, and wherein the evolved object data is determined therefrom.

Optionally, the altered state data is determined based on the one of the one or more player's interaction with the active object.

Optionally, the evolved object data is representative of an evolution of at least one of a behavioral, visual or functional characteristic of the active object.

Optionally, the first state and second state of the active object are controlled by the client-side module.

In some embodiments, the present specification discloses a computer-implemented method of spawning and activating a scriptable object in a game space for multiple players, each of said multiple players using respective client devices to be in data communication with at least one server that simulates the game space on each of the client devices, wherein the at least one server executes a server-side module and each of the client devices executes a client-side module, the method comprising: generating, by the server-side module, data indicative of a seed associated with the scriptable object; communicating, by the server-side module, said data indicative of said seed to a player's client-side module; acquiring, by the player's client-side module, data indicative of a first location of the player in the game space during gameplay; receiving and interpreting, by the player's client-side module, said data indicative of said seed to generate an identification of the scriptable object, a first condition for spawning the scriptable object and a second location in the game space for spawning the scriptable object; spawning, by the player's client-side module, the scriptable object at the second location if the first condition is fulfilled; and activating, by the player's client-side module, the spawned scriptable object if a second condition is fulfilled.

Optionally, the seed is a randomly generated numeric or alphanumeric vector.

Optionally, the numeric or alphanumeric vector is of 32 bits.

Optionally, the activating is based on at least one state and attribute associated with the scriptable object.

Optionally, the scriptable object is not spawned and the seed is discarded by the client-side module if the first condition is not fulfilled.

Optionally, the second condition is fulfilled if the first location is proximal to the second location.

Optionally, the spawned object is not activated if the second condition is not fulfilled.

The aforementioned and other embodiments of the present specification shall be described in greater depth in the drawings and detailed description provided below.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features and advantages of the present specification will be appreciated, as they become better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:

FIG. 1 is a block diagram illustration of a multi-player online gaming system or environment, in accordance with some embodiments of the present specification;

FIG. 2 illustrates exemplary database tables configured to organize and store a plurality of data related to active objects, in accordance with some embodiments of the present specification;

FIG. 3 is a flowchart of a plurality of exemplary steps of a method of procedural generation or spawning and activation of a scriptable/active object in a game space or map, in accordance with some embodiments of the present specification;

FIG. 4A is a flowchart of a plurality of exemplary steps of a first method of managing states and evolution of scriptable/active objects in a game space, in accordance with some embodiments of the present specification;

FIG. 4B is a flowchart of a plurality of exemplary steps of a second method of managing states and evolution of active objects in a game space, in accordance with some embodiments of the present specification;

FIG. 4C is a flowchart of a plurality of exemplary steps of a third method of managing states and evolution of active objects in a game space, in accordance with some embodiments of the present specification; and

FIG. 5 illustrates a plurality of exemplary GUIs (Graphical User Interfaces) to enable an administrator to associate one or more states and attributes to an active object, in accordance with some embodiments of the present specification.

DETAILED DESCRIPTION

The present specification is directed towards multiple embodiments. The following disclosure is provided in order to enable a person having ordinary skill in the art to practice the invention. Language used in this specification should not be interpreted as a general disavowal of any one specific embodiment or used to limit the claims beyond the meaning of the terms used therein. The general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Also, the terminology and phraseology used is for the purpose of describing exemplary embodiments and should not be considered limiting. Thus, the present invention is to be accorded the widest scope encompassing numerous alternatives, modifications and equivalents consistent with the principles and features disclosed. For purpose of clarity, details relating to technical material that is known in the technical fields related to the invention have not been described in detail so as not to unnecessarily obscure the present invention.

The term “a multi-player online gaming environment” or “massively multiplayer online game” may be construed to mean a specific hardware architecture in which one or more servers electronically communicate with, and concurrently support game interactions with, a plurality of client devices, thereby enabling each of the client devices to simultaneously play in the same instance of the same game. Preferably the plurality of client devices number in the dozens, preferably hundreds, preferably thousands. In one embodiment, the number of concurrently supported client devices ranges from 10 to 5,000,000 and every whole number increment or range therein. Accordingly, a multi-player gaming environment or massively multi-player online game is a computer-related technology, a non-generic technological environment, and should not be abstractly considered a generic method of organizing human activity divorced from its specific technology environment.

In various embodiments, a computing device includes an input/output controller, at least one communications interface and system memory. The system memory includes at least one random access memory (RAM) and at least one read-only memory (ROM). These elements are in communication with a central processing unit (CPU) to enable operation of the computing device. In various embodiments, the computing device may be a conventional standalone computer or alternatively, the functions of the computing device may be distributed across multiple computer systems and architectures.

In some embodiments, execution of a plurality of sequences of programmatic instructions or code enable or cause the CPU of the computing device to perform various functions and processes. In alternate embodiments, hard-wired circuitry may be used in place of, or in combination with, software instructions for implementation of the processes of systems and methods described in this application. Thus, the systems and methods described are not limited to any specific combination of hardware and software.

The term “module”, “application” or “engine” used in this disclosure may refer to computer logic utilized to provide a desired functionality, service or operation by programming or controlling a general purpose processor. Stated differently, in some embodiments, a module, application or engine implements a plurality of instructions or programmatic code to cause a general purpose processor to perform one or more functions. In various embodiments, a module, application or engine can be implemented in hardware, firmware, software or any combination thereof. The module, application or engine may be interchangeably used with unit, logic, logical block, component, or circuit, for example. The module, application or engine may be the minimum unit, or part thereof, which performs one or more particular functions.

In the description and claims of the application, each of the words “comprise” “include” and “have”, and forms thereof, are not necessarily limited to members in a list with which the words may be associated. It should be noted herein that any feature or component described in association with a specific embodiment may be used and implemented with any other embodiment unless clearly indicated otherwise.

As used herein, the indefinite articles “a” and “an” mean “at least one” or “one or more” unless the context clearly dictates otherwise.

FIG. 1 illustrates an embodiment of a multi-player online gaming or massively multiplayer online gaming system/environment 100 in which the systems and methods of the present specification may be implemented or executed. The system 100 comprises client-server architecture, where one or more game servers 105 are in communication with one or more client devices 110 over a network 115. Players and non-players, such as computer graphics artists or designers, may access the system 100 via the one or more client devices 110. The client devices 110 comprise computing devices such as, but not limited to, personal or desktop computers, laptops, Netbooks, handheld devices such as smartphones, tablets, and PDAs, gaming consoles and/or any other computing platform known to persons of ordinary skill in the art. Although three client devices 110 are illustrated in FIG. 1, any number of client devices 110 can be in communication with the one or more game servers 105 over the network 115.

The one or more game servers 105 can be any computing device having one or more processors and one or more computer-readable storage media such as RAM, hard disk or any other optical or magnetic media. The one or more game servers 105 include a plurality of modules operating to provide or implement a plurality of functional, operational or service-oriented methods of the present specification. In some embodiments, the one or more game servers 105 include or are in communication with at least one database system 120. The database system 120 stores a plurality of game data (and game files) associated with at least one game that is served or provided to the client devices 110 over the network 115. In some embodiments, the one or more game servers 105 may be implemented by a cloud of computing platforms operating together as game servers 105.

In accordance with aspects of the present specification, the one or more game servers 105 provide or implement a plurality of modules or engines such as, but not limited to, a master game module 130 and a server-side active object (AO) module 132. The one or more client devices 110 are configured to implement or execute one or more of a plurality of client-side modules some of which are same as or similar to the modules of the one or more game servers 105. In some embodiments each of the player and non-player client devices 110 executes a client-side game module 130′ (also referred to as—client game module 130′) that integrates a client-side active object (AO) module 132′.

In some embodiments, the at least one non-player client device 110g is used by an administrator to log into the one or more game servers 105 (via the client game module 130′) and execute the module 132 on the server to generate one or more GUIs that enable the administrator to define and associate one or more states and attributes to an active object. It should be appreciated that the administrator includes computer graphics designers or artists, members of visual effects teams, gameplay engineers and any other non-player personnel responsible for design and development of the game.

While various aspects of the present specification are being described with reference to functionalities or programming distributed across modules or engines 130 and 132, it should be appreciated that, in some embodiments, some or all of the functionalities or programming associated with these modules or engines may be integrated within fewer modules or in a single module—such as, for example, in the master game module 130 itself on the server side and integrating the module 132′ in the client gaming module 130′ on the client side.

In embodiments, the master game module 130 is configured to execute an instance of an online game to facilitate interaction of the players with the game. In embodiments, the instance of the game executed may be synchronous, asynchronous, and/or semi-synchronous. The master game module 130 controls aspects of the game for all players and receives and processes each player's input in the game. In other words, the master game module 130 hosts the online game for all players, receives game data from the client devices 110 and transmits updates to all client devices 110 based on the received game data so that the game, on each of the client devices 110, reflects the interactions of all players with the game. Thus, the master game module 130 transmits game data over the network 115 to the client devices 110 for use and rendering by the game module 130′ to provide local versions and current status of the game to the players.

On the client-side, each of the one or more player client devices 110 implements the game module 130′ that operates as a gaming application to provide a player with an interface between the player and the game. The game module 130′ generates the interface to render a virtual environment, virtual space, game space, map or virtual world associated with the game and enables the player to interact in the virtual environment to perform a plurality of game and other tasks and objectives. The game module 130′ accesses at least a portion of game data, received from the game server 105, to provide an accurate representation of the game to the player. The game module 130′ captures and processes player inputs and interactions within the virtual world or environment and provides at least a portion as updates to the game server 110 over the network 115.

The database system 120 described herein may be, include, or interface to, for example, an Oracle™ relational database sold commercially by Oracle Corporation. Other databases, such as Informix™, DB2 (Database 2) or other data storage, including file-based, or query formats, platforms, or resources such as OLAP (On Line Analytical Processing), SQL (Structured Query Language), a SAN (storage area network), Microsoft Access™ or others may also be used, incorporated, or accessed. The database system 120 may comprise one or more such databases that reside in one or more physical devices and in one or more physical locations. In some embodiments, a plurality of data associated with or corresponding to active objects is stored or built-in to the game's memory space (allocated at one or both the server-side and the client side) and is initialized by loading in the game space or map data as part of the game's payload.

In accordance with aspects of the present specification, at least some active objects are game assets with which a player can interact during gameplay. Persons of ordinary skill in the art should appreciate that not all active objects can be interacted with and there are many assets that are part of the virtual game world without requiring direct interaction. An active object has associated therewith one or more states that can change based on the progress of the game and/or an interaction of the player with the active object. In embodiments, each of the one or more states may have associated one or more attributes or traits that determine behavioral characteristics of the active object in each of the one or more states. Non-limiting examples of active objects include loot items, loot boxes, doors, weapons, cars, vehicles, windows, and other characters.

In embodiments, active objects may be of a first type, referred to as random objects, or of a second type, referred to as non-random objects. Random objects have traits, timings, and/or game space locations which are left to chance. Specifically, random objects are randomly or pseudo-randomly generated and spawned during the game. A non-limiting example of random objects is “loot” such as coins, reward points, skills, weapons, armors, or other treasure.

Non-random objects are programmed to be spawned at specific game space locations at specific times and have specific attributes or traits. Thus, designers may determine that specific locations in the game space should have a particular object associated with it. For example, a car may be parked at a predefined coordinate location, an avatar may be hiding at a specific coordinate location or a door may be positioned at a specific coordinate location (in game space) such as one corresponding to an entry to a castle.

Active objects, whether random or non-random, may be characterized by one or more states reflecting attributes or traits of the object. Generally, game designers will design objects to have those states that are relevant to game play. For example, a door object may have a first state corresponding to the door being closed and a second state corresponding to the door being open. The first state may have an associated attribute or trait that the closed door may glimmer or glow. The second state may have an associated attribute or trait that the opened door may be grayed out or that the glimmer/glow is eliminated.

A game space or map may have a multitude of nodes or locations defined using coordinates. Each of these nodes or locations may spawn random or non-random objects depending at least upon one or more objects and/or progress of the game. At an initialization of game play, therefore, the initial game space may have random objects and non-random objects allocated at defined coordinate locations in the game space. Each of the random and non-random objects may have associated one or more states. In an example, for a random loot object a first state may correspond to the loot existing and a second state may correspond to the loot having been picked up. For a non-random window object a first state may correspond to the window being intact and a second state may correspond to the window being broken. Each object state may have one or more associated attributes or traits. For example, if the loot is in the first state then the loot object may visually sparkle and/or spin (an attribute or trait) whereas if the loot is in the second state then the loot object may visually appear to be grayed out (an attribute or trait). The window object in the first state may reflect (an attribute or trait) whereas in the second state it may crackle (an attribute or trait).

In some embodiments, the database system 120 stores a plurality of data organized into one or more data structures or schemas such as, for example, database tables. In embodiments, the server-side AO module 132 implements a plurality of programmatic instructions or code to access, query and update, during gameplay, the plurality of data organized into the one or more database tables.

FIG. 2 illustrates exemplary database tables configured to organize and store a plurality of data related to active objects, in accordance with some embodiments of the present specification. A first database table 200a stores a first plurality of data related to one or more active objects. For example, in the table 200a a first active object (coins) 202 has associated data indicative of first, second and third states 204, 206, and 208. Data for the first state 204 indicates that all coins are available for acquiring by a player, data for the second state 206 indicates that a lower number of coins are available for acquiring by the player (because some of the coins may already have been won or acquired by another player), and data for the third state 208 indicates that no coins are available (since all coins have already been acquired by other players). The first active object 202 also has associated data indicative of a location 210 and at least one event 212. Data for the location 212 indicates the game space node or coordinates at which the active object 202 should be generated. Data for the event 212 indicates a condition or criteria, for example, that must be satisfied for the active object 202 to be generated at the location 210.

A second database table 200b stores a second plurality of data related to at least one attribute or trait associated with each of the first, second and third states 204, 206 and 208 of the first active object 202. For example, data for attribute 214 associated with the first state 204 indicates that in the first state the coins should visually sparkle with high color intensity, data for attribute 216 associated with the second state 206 indicates that in the second state the coins should visually sparkle with medium color intensity and data for attribute 218 associated with the third state 208 indicates that in the third state the coins should appear visually inactive and grayed out.

Similarly, as shown in the first database table 200a, a second active object (window) 215 has associated data indicative of first and second states 217 and 219. Data for the first state 217 indicates that the window is intact or unbroken while data for the second state 219 indicates that the window is broken or shattered. The second active object 215 also has associated data indicative of a location 221 and at least one event 223. A third database table 200c stores a third plurality of data related to at least one attribute or trait associated with each of the first and second states 217, 219 of the second active object 215. For example, data for attribute 225 associated with the first state 217 indicates that in the first state the window should reflect light and prevent viewing through the window, and data for attribute 227 associated with the second state 219 indicates that in the second state the window should crackle and allow viewing through the window.

Each of the first and second active objects 202, 215 may be further uniquely identified by a primary key (a unique alphanumeric or numeric ID) in the table 200a. It should be appreciated that the database tables 200a, 200b and 200c are exemplary and that the same data may be organized into different schemas.

In some embodiments, for example, the plurality of data pertaining to active objects is organized and stored in the memory space of the game, for example, as part of game files, and initialized by loading in the game level or map data which is part of the game's payload. In some embodiments, the plurality of data pertaining to active objects is organized into following groups:

• • Read-only data present in game files, which defines the attributes, traits or behaviors of each type of object (one definition per type, not per instance);
  • Read only data present in the game files that defines the properties of each instance—their type, position (or coordinates), and sometimes additional information like name or variants;
  • Runtime mutable data that represents the current state an object is in, typically 0 at the start. In every frame, that state is used to tick a state machine based on the read-only data; and
  • Runtime mutable data that represents some of the major properties of the object instances—their position, model, collision, etc.

In some embodiments, an active object (with which a player is allowed to interact) may have at least first and second parts wherein each part may be owned and tracked concurrently and independently. For example, the first part and the states as well as attributes related thereto may be owned and tracked by the server-side AO module 132 while the second part and the states as well as attributes related thereto may be owned and tracked by the client-side AO module 132′. The first and second parts may be respectively tracked by the server-side and client-side modules concurrently and independently.

FIG. 3 is a flowchart of a plurality of exemplary steps of a method 300 of procedural generation or spawning and activation of a scriptable/active object in a game space or map, in accordance with some embodiments of the present specification. In some embodiments, the method 300 is implemented by the server-side and client-side modules 132, 132′ within the system 100 of FIG. 1. As known to persons of ordinary skill in the art, scriptable objects can either be placed in a game space or map by a computer graphics designer or artist, for example, or may be spawned at runtime based on gameplay logic. When placed in the game space or map, the scriptable objects are either conditionally spawned (for example, loot) and/or just explicitly present (for example, doors, a destructible). In embodiments, the conditionally spawned scriptable objects are randomly generated in client devices based on a seed generated and sent to the client devices by the server.

At step 302, the server-side AO module 132 generates a random (or pseudorandom) seed specifying or identifying a scriptable object that may be spawned conditionally and a game space node, location or coordinates at which the scriptable object should be generated or spawned. In some embodiments, the random seed is a short numeric or alphanumeric vector of ‘n’ bits that is randomly generated. In some embodiments, the random seed is a 32-bit vector.

It should be appreciated that apart from conditionally spawned objects, there may be one or more objects (for example, doors or waterfalls) that may be explicitly present but may be in an inactive state, in some embodiments. In some embodiments, at least some of the explicitly present objects can be interacted with by a player. State and attributes data of such explicitly present scriptable objects is accessible from the game's memory space (locally on the player' client device), in some embodiments.

At step 304, the server-side AO module 132 sends the random seed to a player's client-side AO module 132′ on his client game module 130′. At step 306, the client-side AO module 132′ acquires a current location or coordinates of the player in the game space. At step 308, the client-side AO module 132′ interprets the random seed to yield an identification of the scriptable object, a condition (such as, for example, a predefined score being achieved or exceeded by the player, or a predefined set of hurdles or obstacles being overcome by the player) to be met for spawning the object and the object spawning node or location in the game space.

At step 310, the client-side AO module 132′ determines if the spawning condition is met. If yes, then, at step 314, the scriptable object is generated or spawned at the object spawning node or location. In some embodiments, the client-side AO module 132′ accesses a locally stored (on the player's client device) instance of one or more objects data structures or related game files in order to determine the scriptable object (along with associated one or more states and attributes data corresponding to the one or more states) to be rendered based on the identification of the object. It should be appreciated that, in accordance with aspects of the present specification, the object may be spawned conditionally but it may not be active (that is, the object may be spawned in an inactive state). If the spawning condition is not met then, at step 312, the random seed is discarded and the object is not spawned.

At step 316, the client-side AO module 132′ compares the player's current location or coordinates with the conditionally spawned object location to determine if the conditionally spawned object location is proximal or close to the player's current location. If yes, then at step 320, the client-side AO module 132′ activates the conditionally spawned object based on the associated state and attributes data. In some embodiments, the client-side AO module 132′ may also activate at least one explicitly present object if the player's current location or coordinates is determined to be proximal to the at least one explicitly present object.

However, if at step 316, the client-side AO module 132′ determines that the conditionally spawned object location is substantially away from the player's current location then, at step 318, the client-side AO module 132′ does not activate the conditionally spawned object. Similarly, the at least one explicitly present object is also not activated if the at least one explicitly present object location is substantially away from the player's current location.

In some embodiments, activation of an object, based on associated state and attributes data, indicates that the object (conditionally spawned and/or explicitly present) is visible (that is, the object model is drawn or rendered) to the player and its states and attributes are now functional or executable. It should be appreciated that certain objects are visible from a larger distance than others (example, doors versus loot).

In some embodiments, the server-side AO module 132 receives data indicative of the player's in-game inputs and interactions with various active objects. Concurrently, the client-side AO module 132′ also receives the data indicative of the player's in-game inputs and interactions with various active objects.

In accordance with some aspects of the present specification, the server-side and client-side AO modules 132, 132′ concurrently and independently perform the following tasks:

• • Determine an initial or first state of an active object during gameplay
  • Monitor and determine on-going changes to the states of the active object as a result of the game progress and/or an interaction of the player with the active object. That is, determine if the first state has changed to a second state, the second state has changed to a third state and so on depending upon the one or more states associated with the active object.
  • Determine how the active object changes, to an evolved active object, based on the new state and on at least one attribute or trait associated with the new state. For example, the player may pick up loot, causing the server-side and client-side AO modules 132, 132′ to recognize an associated change from the first state to the second state. In alternate embodiments, altered state data indicative of a change from a first state to a second state is acquired by the server-side AO module 132 which then sends the altered state data to the client-side AO module 132′. Based on the altered state data, the AO modules 132, 132′ concurrently and independently determine how the active object should change or evolve. It should be appreciated that the altered state data is a substantially small amount of information that is communicated between the server-side and client-side AO modules 132, 132′. In some embodiments, altered state data indicative of a change from a first state to a second state causes the AO modules 132, 132′ to perform different tasks. For example, the altered state data may cause the server-side AO module 132 to make a weapon unavailable for pickup and give it to a player whereas the altered state data may cause the client-side AO module 132′ to stop playing a sound that was previously playing or stop displaying a visual effect that was previously being displayed.

In some embodiments, alteration of a state of an active object is affected depending on whether the state of the active object (or a part/portion of the active object) is owned by the server-side AO module 132 or by the client-side AO module 132′. If the state of the active object is owned by the server-side AO module 132, the client-side AO module 132′ changes the state of the active object only if it receives a message (related to altered state data) from the server-side AO module 132. That is, based at least on a player's interaction with an active object, the server-side AO module 132 monitors and determines on-going changes to the states of the active object, sends the altered state data to the client-side AO module 132′ and thereafter both server-side and client-side AO modules 132, 132′ concurrently and independently change the active object into an evolved active object based on the altered state data.

However, if the state of the active object (or a part/portion thereof) is owned by the client-side module 132′, the AO module 132′ goes ahead and changes the state of the active object. The altered state data for the state of the active object (or a part/portion thereof) owned by the module 132′ is not communicated to other players' client devices. For example, doors have specific programmatic code associated therewith to enable the doors to be client-predicted. It should be appreciated that, in some embodiments, an active object may have first and second parts wherein the first part may be owned by the AO module 132 (in terms of state changes) and the second part may be owned by the AO module 132′. Thus, in some embodiments, data corresponding to state change of the second part (that is owned by the client-side AO module 132′) is not shared or communicated to other players' client devices as part of an option to optimize performance and bandwidth use. Following are non-limiting exemplary scenarios in which the altered state data of the second part (that is owned by the client-side AO module 132′) is not shared, communicated to or replicated across other players' client devices:

a) Events or situations where it is not necessary or required to keep all client devices in sync such as for non-gameplay impactful objects, clutter objects and dynamic environmental impacts or enhancements—for example, birds flocking or flying away when a player approaches them, flickering decorative lights and TV sets that can be switched on and off.b) Cases where the server-side AO module 132 is allowed to change the state but not required to replicate that state change to any client device if it is predetermined that the state change has no impact across client devices such as, for example, if the events generated by the state change only trigger a script call back (which only exists on the server).c) Cases where the trigger itself, for a change of state, is deterministic or close to being deterministic across all client devices. As a non-limiting example, an explosion may be a trigger for change of state of the second parts of one or more objects. The explosion being a deterministic event, all client devices can resultantly go ahead and alter the state of the second parts of the one or more objects and the altered state data (related to the one or more objects) is not required to be communicated or shared across client devices. In another non-limiting example, a player's interaction with a scriptable/active object may already be replicated across client devices as part of a shared data stream. Therefore, the system can rely on this shared data stream to impact the scriptable object (by way of state change) in a consistent manner and so the scriptable object itself does not have to redundantly replicate that state change.

It should be appreciated that, in some embodiments, graphics designers author one or more scriptable/active objects, having a second part owned by the client-side AO module 132′, keeping in mind that the client-side AO module 132′ may go ahead and alter the state of the second part of the scriptable/active object, not share or communicate the altered state data across other player's client devices and therefore generate a possibility of inconsistency of how the scriptable/active object is rendered across multiple client devices. Therefore, the gaming system recognizes that players who join late into the game, for example, will never have a chance to see the state changes or trigger events, and the gaming system considers that to be acceptable when the choice is made to make a part of a scriptable/active object client owned or authoritative.

• • Arrive at the same current or new state of the active object as well as the same evolved active object concurrently yet independently of each other.

It should be appreciated that, in some embodiments, the server-side AO module 132 has one state of the virtual world for all players. For state of an active object (or a part thereof) owned by the server-side AO module 132, the AO module 132 keeps track of what each client knows about the state of the world from the perspective of the module 132. For each frame, the server-side AO module 132 looks at its own current altered state of the active object, and sends a list of altered state data indicative of state updates to each client device for which the state does not match. In some embodiments, a predefined limit is applied on how much altered state data can be communicated in a single frame (for example, depending upon bandwidth cap) as a result of which the client devices may get slightly out of sync with the server. However, this aberration will tend to correct itself over time.

On the other hand, as described earlier, in some embodiments, altered state of an active object (or a part thereof) owned by the client-side AO module 132′ is not reflected to other players' client devices. Thus, only the altered state of an active object (or a part thereof) owned by the server-side AO module 132 is replicated to all players' client devices.

For state of an active object (or a part thereof) such as, for example, a door, so long as the player's movement and actions are predicted accurately by the modules 132 and 132′, both modules 132, 132′ will deterministically arrive at the same final state, concurrently and independently. If a non-predicted event or element is introduced (which a client device did not anticipate) as a result of which the player is interrupted (for example, if another player gets in the way of opening the door) then the non-predicted event or element is sensed by the server-side module 132. Consequently, the module 132 is configured to correct the state of the client device (in light of the sensed non-predicted event or element) thereby causing a visible correction on the client device. Therefore, in some embodiments, for client-predicted state changes (example, for the doors) the server-side AO module 132 is still responsible for sending the modified or altered state data to client devices. In embodiments, this behavior relies on pre-existing frameworks in the master game module or engine 130 that allow for the predictive simulation of the player inputs and movement. Thus, both server-side and client-side AO modules 132, 132′ are provided with a certain set of inputs and instructions to move the player. As a result of the inputs both modules 132, 132′ will usually arrive at the same predicted output or conclusion. Subsequently, the client-side AO module 132′ sends its predicted output (via a hash of such outputs) to the server-side AO module 132. The server-side AO module 132 determines if its own predicted output matches with the predicted output of the client-side AO module 132′ and when the two predicted outputs do not match, perhaps because the inputs of the modules 132, 132′ did not match, the server-side AO module 132 will correct the client-side AO module 132′. In that sense, both server-side and client-side modules 132, 132′ are tasked with calculating the player's movement and actions, but the calculated movements and actions of the player by the client-side module 132′ is considered as ‘predicted’ and that by the server-side module 132 is considered to be ‘authoritative’.

In some embodiments, the server-side AO module 132 processes a player's movement and action to recognize a new state for an active object (the state of which is owned by the server-side AO module 132), generate an evolved active object based on the new state, and then send evolved object data indicative of the evolved active object back to the client game module 130′ for rendering. On the other hand, the client game module 130′ implements the client-side AO module 132′ that either determines and implements on-going changes to the state of an active object (the state of which is owned by the client-side AO module 132′) or receives, from the server-side AO module 132, altered state data for an active object (the state of which is owned by the server-side AO module 132) and concurrent to the server-side AO module 132 independently yields or generates an evolved active object.

FIG. 4A is a flowchart of a plurality of exemplary steps of a method 400a of managing states and evolution of scriptable/active objects in a game space, in accordance with some embodiments of the present specification. In embodiments, each of the steps 402, 404, 406 and 408 of the method 400a are implemented, concurrently and independently, by the server-side and client-side AO modules 132, 132′ in the system 100 of FIG. 1. Note that the sequences of the steps of the method 400a are exemplary and may change in alternate embodiments. For example, in some embodiments, step 412 may be performed prior to step 410.

At step 402, the server-side and client-side AO modules 132, 132′ acquire data indicative of a player's in-game inputs, responses and interactions with an active object during gameplay. In some embodiments, the active object may have associated one or more states and each of the one or more states may have associated at least one attribute or trait that defines behavioral, visual and/or functional characteristics of the active object.

In some embodiments, the active object has at least first and second parts. The first part and the states as well as attributes related thereto is owned and tracked by the server-side AO module 132 while the second part and the states as well as attributes related thereto is owned and tracked by the client-side AO module 132′. The first and second parts are respectively tracked by the server-side and client-side modules concurrently and independently.

At step 404, the server-side module 132 determines initial state data indicative of an initial or first state of the first part (owned and tracked by the server-side module 132) of the active object while the client-side module 132′ determines initial state data indicative of an initial or first state of the second part (owned and tracked by the client-side module 132′) of the active object, from the associated one or more states. The active object may have an initial or first attribute or trait associated with each of the initial or first states of the first and second parts of the active object.

At step 406, the server-side module 132 determines altered state data indicative of a next or second state of the first part while the client-side module 132′ determines altered state data indicative of a next or second state of the second part of the active object resulting from the player's in-game inputs, responses and interactions with the active object. Accordingly, a “next state” is a state that is subsequent, immediately after, or otherwise comes after, in time, the initial or first state. The active object may have a next or second attribute or trait associated with each of the next or second states of the first and second parts of the active object. Thus, the server-side and client-side AO modules 132, 132′ determine, for their respective first and second parts, if a first state has changed to a second state, the second state has changed to a third state and so on depending upon the one or more states associated with each part of the active object.

At step 408, the server-side and client-side AO modules 132, 132′ determine, for their respective first and second parts, evolved object data (based on the altered state data) indicative of a change from the first attribute or trait to the second attribute or trait. The change from the first to second attribute is representative of an evolution of the behavioral, visual and/or functional characteristics of each of the first and second parts of the active object. Accordingly, evolved object data is based on altered state data and is representative of a change from the first attribute or trait to the second attribute or trait.

At step 410, the client-side AO module 132′ uses the evolved object data for the second part to render the second part of the active object in the second state with associated second attribute or trait. In some embodiments, altered state of the second part of the object owned by the client-side AO module 132′ is not reflected to other players' client devices in order to optimize performance and bandwidth use. In some embodiments, however, the rendering of the second part is conditional and dependent at least upon a location or coordinates of the active object with reference to the player's current location or coordinates. Thus, in some embodiments, the client-side AO module 132′ uses the evolved object data for the second part to render the second part of the active object in the second state with associated second attribute or trait if the player's current location or coordinates is in proximity to the location or coordinates of the active object. If not, then, in some embodiments, the client-side module 132′ may not render the second part of the active object in the second state.

At step 412, the server-side AO module 132 sends the altered state data of the first part (determined at step 406) to client-side modules 132′ (or client devices) of all other players (that is, players other than the player who interacted with the active object at step 402), including the player who interacted with the active object, irrespective of where the players are positioned or located within the game space.

In some embodiments, the server-side AO module 132 may follow a prioritization scheme for sending of the altered state data of the first part of the active object to a player's client-side module 132′ (or client device) in case network bandwidth limit is breached at the player's client device and becomes throttled (which is an edge-case condition, typically seen for players joining late in a match).

In embodiments, the game virtual world is initially partitioned into a two dimensional (2D) grid at server startup. The size and number of grid cells depends on the size of the game map. When active objects are spawned, they are assigned to the grid cell in which they belong spatially. When the server-side AO module 132 prioritizes sending of altered state data to a player's client device (due to network bandwidth limits being breached at the player's client device), the server-side AO module 132 first sends the altered state data for the cell the player is currently located in, then the neighboring cells, then further out, until no more altered state data remains to be sent or the bandwidth capacity is met for the current frame.

In some embodiments, the client-side AO modules 132′ are configured to act upon the received altered state data of the first part depending upon locations of associated players in the game space. Thus, for all players that are in locations proximal to the active object the respective client-side AO modules 132′ use the received altered state data of the first part and use the evolved object data of the first part in order to change the state and implement the attributes or traits associated with the changed state of the first part of the active object. Thus, in some embodiments, the client-side AO modules 132′ are configured to not act upon the received altered state data of the first part if the associated players are currently positioned or located substantially away from the position or location of the active object.

Thus, at step 414, it is up to the client-side AO module 132 that is configured to decide whether to act (or not act) upon the received altered state data of the first part, use (or not use) the evolved object data of the first part and render (or not render) the first part of the active object in the second state with associated second attribute or trait.

FIG. 4B is a flowchart of a plurality of exemplary steps of a method 400b of managing states and evolution of scriptable/active objects in a game space, in accordance with some embodiments of the present specification. In embodiments, the method 400b is implemented by the server-side and client-side AO modules 132, 132′ in the system 100 of FIG. 1. In embodiments, some of the steps of the method 400b are implemented concurrently and independently by the server-side and client-side AO modules 132, 132′. The method 400b is implemented for those active objects the states for whom are owned by the server-side AO module 132 and also for those active objects that support player interaction.

At step 420, the server-side module 132 acquires data indicative of a player's in-game inputs, responses and interactions with an active object during gameplay. In various embodiments, the active object may have associated one or more states and each of the one or more states may have associated at least one attribute or trait that defines behavioral, visual and/or functional characteristics of the active object.

The initial state data indicative of an initial or first state of the active object (from the associated one or more states) is known by both the modules 132, 132′ and determined based on pre-generated data that is part of the game files (typically specific to each game level). In some embodiments, the initial state data is computed by the client-side AO module 132′ based on a seed received from the server-side AO module 132 in the case of a randomly generated active object. The active object may have an initial or first attribute or trait associated with the initial or first state of the active object.

At step 424, the server-side module 132 determines altered state data indicative of a next or second state of the active object resulting from the player's in-game inputs, responses and interactions with the active object. The active object may have a next or second attribute or trait associated with the next or second state of the active object. Thus, the server-side module 132 determines if a first state has changed to a second state, the second state has changed to a third state and so on depending upon the one or more states associated with the active object.

At step 426, the server-side module 132 sends the altered state data to the player's client device as well as to all other player's client devices. In some embodiments, the server-side AO module 132 may prioritize sending of altered state data to those player client devices for which the associated players are located or positioned proximal to the active object. Subsequently, the server-side AO module 132 may send the altered state data to all remaining player client devices irrespective of where the players are positioned within the game space.

At step 428, the server-side and client-side AO modules 132, 132′, concurrently and independently, determine evolved object data (based on the altered state data) indicative of a change from the first attribute or trait to the second attribute or trait. The change from the first to second attribute is representative of an evolution of the behavioral, visual and/or functional characteristics of the active object.

At step 430, the client-side AO module 132′ uses the evolved object data to render the active object in the second state with associated second attribute or trait.

In some embodiments, the client-side AO module 132′ determines the evolved object data and uses the evolved object data to render the active object in the second state only if the player is in proximity of the active object.

FIG. 4C is a flowchart of a plurality of exemplary steps of a method 400c of managing states and evolution of scriptable/active objects in a game space, in accordance with some embodiments of the present specification. In embodiments, the method 400c is implemented by the client-side AO module 132′ in the system 100 of FIG. 1. The method 400c is implemented for those active objects the states for whom are owned by the client-side AO module 132′ and also for those active objects that support player interaction.

At step 450, the client-side AO module 132′ acquires data indicative of a player's in-game inputs, responses and interactions with an active object during gameplay. In various embodiments, the active object may have associated one or more states and each of the one or more states may have associated at least one attribute or trait that defines behavioral, visual and/or functional characteristics of the active object.

Initial state data indicative of an initial or first state of the active object (from the associated one or more states) is known by both the modules 132, 132′ and determined based on pre-generated data that is part of the game files (typically specific to each game level). In some embodiments, the initial state data is computed by the client-side AO module 132′ based on a seed received from the server-side AO module 132 in the case of a randomly generated active object. The active object may have an initial or first attribute or trait associated with the initial or first state of the active object.

At step 452, the client-side AO module 132′ determines altered state data indicative of a next or second state of the active object resulting from the player's in-game inputs, responses and interactions with the active object. The active object may have a next or second attribute or trait associated with the next or second state of the active object. Thus, the client-side AO module 132′ determines if a first state has changed to a second state, the second state has changed to a third state and so on depending upon the one or more states associated with the active object.

At step 454, the client-side AO module 132′, independent of the server-side AO module 132, determines evolved object data (based on the altered state data) indicative of a change from the first attribute or trait to the second attribute or trait. The change from the first to second attribute is representative of an evolution of the behavioral, visual and/or functional characteristics of the active object.

At step 456, the client-side AO module 132′ uses the evolved object data to render the active object in the second state with associated second attribute or trait. In some embodiments, the client-side AO module 132′ determines the evolved object data and uses the evolved object data to render the active object in the second state only if the player is in proximity of the active object.

It should be appreciated that, in some embodiments, the altered state data, determined at step 452, is not communicated to other players' client devices at all. In other words, the evolved object is not replicated to other players' client devices in order to optimize performance and bandwidth use.

Thus, in accordance with some aspects of the present specification, the server-side AO module 132 in data communication with the client-side AO module 132′ enables efficient management of an amount of data communicated between the one or more game servers 105 and a client device 110 for desired execution and rendering of a virtual game world or game space during gameplay. In embodiments, the data managed is indicative of the game space including a plurality of active objects associated with the game space.

In various embodiments, an active object is a small bundle of data and programming code or script. A computer graphics designer or artist creates an active object in the form of a scriptable object which is a container of minimal amount of data and script. In some embodiments, the data contained in or bundled with an active object asset defines one or more states of the object (among other data such as, for example, those defining a geometric model of the object and sounds). In some embodiments, the programming code or script contained in or bundled with the active object asset defines how the active object is supposed to behave in each of the one or more states. Thus, in accordance with some aspects of the present specification, the client-side AO module 132′ can interpret the data and execute the script bundled with the active object and, based on a player's interactions with the active object, determine altered state data as well as evolved object data concurrently and independently of the server-side AO module 132. Thus, the client-side AO module 132′ can use script of the active object asset to effect change in behavioral, visual and/or functional characteristics of the active object asset without having to go back to the one or more game servers 105. For example, when a player fires at a window object, a corresponding event is generated and acquired by both the server-side and client-side AO modules 132, 132′ thereby causing the modules 132, 132′ to, concurrently and independently, execute a script bundled with the window object to determine the same result of showing the window broken.

In accordance with some aspects of the present specification, an active object only needs to be defined once, and all associated data (including data defining one or more states as well as the programming code or script defining how the active object is supposed to behave in each of the one or more states) is included in the game files and never needs to be sent from the server to the client. This enables the server-side AO module 132 to replicate or send a substantially small payload (corresponding to altered state data) to a client-side AO module 132′. In some embodiments, the payload is of a single bit when active objects have only two associated states.

Stated differently, data and scripts determining behaviors of active objects are predetermined and defined in the game files so that at runtime data exchange, related to altered state data, between the server and clients is minimized. Thus, the amount of data required to represent what state an object is in, during runtime, is minimized since behavior of the object in different states is predetermined in the game files. In contrast, prior art approach for server-scripted games is for the server to spawn and replicate (to each client) individual sounds, effects, models, etc. which can quickly add to up several KBs of bandwidth.

In accordance with some aspects of the present specification, the server-side AO module 132 generates and provides a software workflow tool to enable an administrator to define and associate one or more states to an active object and also script behavior of the active object by associating at least one attribute or trait with each of the one or more states.

FIG. 5 illustrates a plurality of exemplary GUIs (Graphical User Interfaces) 500 to enable an administrator to associate one or more states and attributes to an active object, in accordance with some embodiments of the present specification. In some embodiments, the GUIs 500 are generated by the server-side AO module 132 in response to the administrator logging into the one or more game servers 105 using his client device 110g. It should be appreciated that the administrator includes computer graphics designers or artists, members of visual effects teams, engineers and any other non-player personnel responsible for design and development of the game.

As shown, a first interface 500a displays a first active object (coins) 502 and a second active object (windows) 504. Button icons 503, 505 when clicked cause generation of a second interface. As an example, when the first button icon 503 is enabled (clicked, for example) a second interface 500b displays first, second and third input fields 508, 510 and 512 for enabling the administrator to input or choose (from a drop down list) data indicative of first, second and third states of the first active object 502. The administrator may click on a button icon 515 to continue adding more states to the first active object 502. On actuating button icon 516, the data indicative of first, second and third states 508, 510, 512 is associated with the first active object 502 and stored in the at least one database 120 (FIG. 1).

The administrator can also associate an attribute or trait to each of the states. For example, if the administrator actuates a button icon 520 (corresponding to the first state 508) a third interface 500c is displayed. The third interface 500c displays, for example, a field 522 for enabling the administrator to input or choose (from a drop down list) programmatic code or script defining an attribute or trait to be associated with the first state 508. On clicking a submit button icon 524, the programmatic code or script defining the attribute or trait 522 is associated with the first state 508 of the first active object 502 and stored in the at least one database 120.

It should be appreciated that the GUIs 500 are only exemplary and the workflow of defining states and attributes for an active object may be implemented in fewer or more GUIs in various alternate embodiments. The GUIs 500 define a workflow that enables the administrator to define states and script behaviors of an active object in a game world and gives them the opportunity to push specific functions for client-side execution while some functions are implemented on a server.

The systems and methods of the present specification enable large scale interactability with scriptable/active object assets of the virtual world for example, loot pickups, doors, windows, destructible environment, etc. Conventionally, a server script had to make runtime decisions on what needs to be spawned dynamically and send that information to the client. This costs a significant amount of CPU, memory and network bandwidth, and limits the ability to scale. Embodiments of the present specification allow for shared knowledge of the ‘interactable dynamic world’ and facilitate large-scale virtual worlds by significantly reducing the amount of data required to synchronize the clients with the server (orders of magnitude less bandwidth, for example 100+ bytes down to a single byte per object).

Embodiments of the present specification also allow for a significant amount of processing during the toolchain and use an optimized pipeline at runtime that substantially reduces the CPU need to manage those objects. Rather than use interpreted designer-driven script on a single thread, embodiments of the present specification use a data-driven state machine that runs entirely native code and for which many operations are multithreaded. Embodiments of the present specification also simplify the designer's workflow by automatically activating and de-activating objects that are relevant to each individual player. Conventionally, that kind of object management would have to be managed by various custom systems written by designers and gameplay engineers.

Embodiments of the present specification further allow for up to a million interactable/active objects compared to a typical conventional limit of ˜1000, with the ability to scale further.

The above examples are merely illustrative of the many applications of the systems and methods of present specification. Although only a few embodiments of the present specification have been described herein, it should be understood that the present specification might be embodied in many other specific forms without departing from the spirit or scope of the specification. Therefore, the present examples and embodiments are to be considered as illustrative and not restrictive, and the specification may be modified within the scope of the appended claims.

Claims

1. A method of managing a scriptable object in a game space of a multi-player video game based on interactions of a player with the scriptable object via a client-side device, wherein the multi-player video game is hosted by at least one server, wherein the at least one server is configured to execute a server-side module and wherein the client-side device is configured to execute a client-side module, the method comprising: generating, in the server-side module, a seed and transmitting the seed to the client-side module, wherein the seed is a randomly generated alphanumeric vector of ‘n’ bits and wherein the scriptable object is spawned in the multi-player video game based on said seed;acquiring, by the server-side module and by the client-side module, data indicative of the player's interaction with the scriptable object during a game session of the multi-player video game, wherein the scriptable object comprises a first portion tracked by the server-side module and a second portion tracked by the client-side module;determining, by the server-side module, data indicative of an initial state of the first portion and, by the client-side module, data indicative of an initial state of the second portion;determining, by the server-side module, first altered state data indicative of a next state of the first portion and, by the client-side module, second altered state data indicative of a next state of the second portion;determining, by the server-side module, first evolved object data of the first portion and, by the client-side module, second evolved object data of the second portion; andrendering, by the client-side module, an updated scriptable object based on the first evolved object data and the second evolved object data.

2. The method of claim 1, wherein the initial state of the first portion has an associated first initial attribute and the next state of the first portion has an associated first next attribute, and wherein the initial state of the second portion has an associated second initial attribute and the next state of the second portion has an associated second next attribute.

3. The method of claim 2, wherein the evolved object data of the first portion is indicative of a change from the first initial attribute to the first next attribute of the first portion, and wherein the evolved object data of the second portion is indicative of a change from the second initial attribute to the second next attribute of the second portion.

4. The method of claim 1, wherein the altered state data of the first portion and the altered state data of the second portion is determined based on the player's interaction with the scriptable object.

5. The method of claim 1, wherein rendering of the second portion is performed if the player's location is determined, by the client-side module, to be proximal to a location of the scriptable object in the game space.

6. The method of claim 1, wherein rendering of the first portion is performed if the server-side module sends the altered state data of the first portion to the client-side module.

7. The method of claim 1, wherein the evolved object data of the first portion and the evolved object data of the second portion are representative of an evolution of at least one of a behavioral, visual or functional characteristic of the scriptable object.

8. The method of claim 1, further comprising, in the client-side module, acquiring a current location or coordinates of a virtual character controlled by the player in the game space.

9. The method of claim 1, further comprising, in the client-side module, interpreting the seed to yield an identification of the scriptable object and one or more conditions to be met for spawning the scriptable object in the game space.

10. The method of claim 9, further comprising, in the client-side module, determining if the one or more conditions are met and, based on the one or more conditions being met, spawning the scriptable object.

11. The method of claim 10, further comprising, in the client-side module, accessing a locally stored instance of one or more data structures or related files in order to render the scriptable object.

12. The method of claim 9, further comprising, in the client-side module, determining if the one or more conditions are met and, based on the one or more conditions not being met, not spawning the scriptable object and discarding the seed.

13. The method of claim 10, further comprising, in the client-side module, determining if the one or more conditions are met and, based on the one or more conditions not being met, not spawning the scriptable object and discarding the seed.

14. The method of claim 10, further comprising, in the client-side module, comparing the player's current location or coordinates with a location of the spawned scriptable object to determine if the spawned scriptable object is close to the player's current location or coordinates.

15. The method of claim 14, further comprising, in the client-side module, when the spawned scriptable object is close to the player's current location or coordinates, activating the spawned scriptable object.

16. The method of claim 14, further comprising, in the client-side module, when the spawned scriptable object is not close to the player's current location or coordinates, not activating the spawned scriptable object.