U.S. Pat. No. 11,413,527

DETAILED DESCRIPTION

FIG. 1illustrates a system100configured for using re-playable in-game operations to reach particular user game states in one or more gaming platforms105(e.g., an online gaming platform), in accordance with one or more implementations. In some implementations, system100may include one or more of electronic storage130, one or more servers102, one or more client computing platforms104, one or more gaming platforms105, one or more blockchains111(e.g., a distributed blockchain), one or more external resources128, and/or other components.

Server(s)102may be configured to communicate with one or more client computing platforms104according to a client/server architecture and/or other architectures. Client computing platform(s)104may be configured to communicate with other client computing platforms via server(s)102and/or according to a peer-to-peer architecture and/or other architectures. Users123may access system100via client computing platform(s)104. Users123may include one or more of a first user, a second user, a third user, a fourth user, and/or other users. In some implementations, users123may include one or more creating users, requesting users, selling users, buying users, owning users, and/or other users. In some implementations, one or more users123do not need to be players of any gaming platform.

In some implementations, system100and/or servers102may be configured to communicate with one or more of (online) gaming platform(s)105, users123, blockchain(s)111, and/or other components. As used herein, gaming platform105may refer to either an individual game, a type of gaming console and its ecosystem, and/or both. Gaming platform105may be operated, hosted, and/or owned by a stakeholder of gaming platform105. Users123may include players who play on gaming platform105. In some implementations, gaming platform105may include an online store that sells and/or otherwise transfers (in-game) virtual items that may be used within gaming platform105.

As used herein, the term “game state” may refer to some or all of the variables that define the progress and/or status of a player and/or the player's account within an online gaming platform, e.g., gaming platform105. For example, in some implementations, users may save the current game state to preserve their progress, and load the saved game state at a future time to restore their progress and/or status as if they had taken no actions after the moment of saving their game state. For example, whatever items or health were lost after the moment of saving the game state would be restored upon loading the saved game state. In some implementations, users may save and/or restore game state at particular save points and/or restore points. In some implementations, save points and/or restore points may be specific locations within a virtual space of an online game such as, for example, the beginning of a level, mission, and/or battle.

As used herein, the term “user game state” may refer to some or all of the variables that define the position of the user (or a user-controlled character) at a particular moment within an online gaming platform (e.g., gaming platform105), such as a location within a virtual space of an online game. The user game state at the current time may be referred to as the current user game state. In some implementations, a current position may include a heading and/or direction of the user or the user-controlled character. In some implementations, a current position may include the posture of the user-controlled character, such as, e.g., laying down, sitting, standing, etc. In some implementations, a current position may include the position of one or more body parts of the user and/or the user-controlled character, such as, e.g., the position of feet, legs, arms, wings, etc. In some implementations, a current position may include a velocity and/or acceleration of the user or the user-controlled character.

An in-game action or operation taken and/or performed by an individual user may advance the current user game state of the individual user to a subsequent user game state of the individual user. For example, a particular user-controlled character controlled by an individual user may be at a location with coordinates (X0, Y0) within a virtual space. This location may be part of the current user game state of the individual user and/or the particular user-controlled character. By taking a step in a particular direction, the subsequent user game state of the individual user and/or the particular user-controlled character may include, define, and/or otherwise be associated with a subsequent location having coordinates (X1, Y1) within the virtual space. Next, by taking another step in a particular direction, the next user game state may be associated with the next location having coordinates (X1, Y2) within the virtual space. Individual user game states may be associated with one or more types of different timing information. For example, the user game state associated with coordinates (X0, Y0) may be associated with a timestamp of t=0, the user game state associated with coordinates (X1, Y1) may be associated with a timestamp of t=1, the user game state associated with coordinates (X1, Y2) may be associated with a timestamp of t=2, and so forth. In some implementations, timestamps do not need to increment by the same amount. For example, if the individual user had waited to the take the next step described above, the user game state associated with coordinates (X1, Y2) may have been associated with a timestamp of t=5.

In some implementations, system100and/or one or more components of system100may be configured to execute an instance of a game (e.g., an online game) to facilitate presentation of the game to users123, and/or to implement in-game actions in the instance of the game, e.g., in response to action requests for the in-game actions by users123. The game may be provided via a virtual space, and may include a plurality of resource types and/or maps. An instance of the virtual space may be executed by one or more computer components to determine views of the virtual space. In some implementations, the view may be communicated (e.g., by streaming, via object/position data, and/or other information) from server(s)102and/or other sources to client computing platforms104for presentation to users123. The view determined and transmitted to a given client computing platform104may correspond to a location in the virtual space (e.g., the location from which the view is taken, the location the view depicts, and/or other locations), a zoom ratio, a dimensionality of objects, a point-of-view, and/or view parameters. In some implementations, one or more view parameters may be selectable by a user.

The instance of the virtual space may include a simulated space that is accessible by users123by clients (e.g., client computing platforms104) that present the views of the virtual space to a user. The simulated space may have a topography, express ongoing real-time interaction by one or more users, and/or include one or more objects positioned within the topography that are capable of locomotion and/or movement within the topography. In some implementations, the topography may be a 2-dimensional topography. In some implementations, the topography may be a 3-dimensional topography. The topography may include dimensions of the simulated space, and/or surface features of a surface or objects that are native to the simulated space. In some implementations, the topography may include a surface (e.g., a ground surface) that runs through at least a substantial section of the simulated space. In some implementations, the topography may describe a volume with one or more bodies positioned therein. The instance executed by the computer components may be synchronous, asynchronous, and/or semi-synchronous.

Within the instance of the virtual space, users123may control characters, objects, simulated physical phenomena, and/or other elements within the virtual space to interact with the virtual space and/or each other. The user characters may include avatars. As used herein, the term “user character” may refer to an object or group of objects present in the virtual space, that correspond(s) to an individual user. A particular user character may be controlled by the particular user with which it is associated. Such user characters may be referred to as user-controlled characters. User-controlled element(s) may move through and interact with the virtual space (e.g., non-user characters in the virtual space, other objects in the virtual space, etc.). User-controlled elements controlled by and/or associated with a given user may be created and/or customized by the given user. Individual users may have an “inventory” of virtual goods and currency (e.g., resources of the plurality of resource types) that the individual user can use (e.g., by manipulation of a user character and/or other user-controlled elements) and/or other items, to perform in-game actions within the virtual space.

In some implementations, a distributed blockchain such as blockchain111may be maintained by a distributed computing platform (not shown inFIG. 1). In some implementations, the distributed computing platform may be implemented by a set of client computing platforms and/or servers. The distributed computing platform may support a virtual machine (not shown inFIG. 1). The distributed computing platform and/or the virtual machine may form a runtime environment for smart contracts and/or other executable code. In some implementations, the distributed computing platform may include electronic storage configured to store part or all of blockchain(s)111. The smart contracts may be stored on blockchain(s)111. In some implementations, the distributed computing platform may be the EOSIO platform. In some implementations, the distributed computing platform may be Ethereum. In some implementations, the virtual machine may be a Turing-complete and decentralized virtual machine.

A distributed blockchain may act as a (decentralized) database that stores a registry of assets and transactions across one or more networks. A given asset may be owned by a particular user. An asset may include anything of material value or usefulness that is owned by or on behalf of a person or company, including but not limited to assets created by asset creating component128, and/or other assets. In some implementations, a right pertaining to an object may be an asset, the object being a physical or a virtual item. Multiple rights may form a set of rights or a bundle of rights that may be transferred and/or otherwise acted on or operated on together. For example, rights may include a right to use, a right to sell, a right to destroy, and/or other rights.

In some implementations, tokens may be a type of asset. In some implementations, tokens may include one or more of security tokens, utility tokens, payment tokens, initial coin offering (ICO) tokens, virtual currency tokens, crypto tokens, ERC-20 tokens, EOS tokens, and/or other tokens. In some implementations, tokens not only represent value, but may have a specific use in a particular distributed computing platform, e.g., in the operation of blockchain111.

In some implementations, blockchain(s)111may record and/or register ownership of assets. Alternatively, and/or simultaneously, blockchain(s)111may register transactions that modify ownership of assets. A smart contract may be a type of asset. In some implementations, once a smart contract has been added to a blockchain, the smart contract may be referred to as published, posted, registered, and/or recorded. Elements of blockchain(s)111may be grouped together in units that are referred to as blocks. For example, an individual block may include one or more assets and one or more transactions. For example, an individual block may be linked to one or more other individual blocks. Individual blocks may be linked or chained together to form a structure of blocks and/or a hierarchy of blocks, such as, e.g., a chain of blocks. An individual block may include one or more assets, one or more transactions, and/or other information.

Blockchain(s)111may be publicly accessible and append-only. In some implementations, existing blocks of a distributed blockchain can substantially not be altered or deleted, unless multiple copies of the distributed blockchain are altered. This is unlikely to happen provided that multiple copies of the distributed blockchain are stored on different computing platforms, e.g., in different geographical locations. The distributed blockchain may be replicated on multiple computing platforms, preferably in multiple different geographical locations.

Server(s)102may be configured by machine-readable instructions106. Machine-readable instructions106may include one or more instruction components. The instruction components may include computer program components. The instruction components may include one or more of management component108, request receiving component110, execution component112, verification performance component114, registration component116, sale component118, transfer component120, assembly component122, asset receiving component124, asset creating component126, and/or other instruction components.

Management component108may be configured to manage user inventories for users123of online gaming platform105. Users123may include a first user, a second user, a third user, and so forth. In some implementations, users123may include a creating user and/or other users. The user inventories may include a first user inventory associated with the first user, a second user inventory associated with the second user, a creating user inventory associated with the creating user, and so forth. In some implementations, a particular user inventory may include a particular virtual good and/or virtual item referred to as a replay asset.

Replay assets may include and/or refer to sets of in-game operations. For example, a particular replay asset may include a particular set of in-game operations. In some implementations, a set of in-game operations may be provided by the creating user, and/or by other providers. For example, in some implementations, a set of in-game operations may be provided by a stakeholder of gaming platform105. Activation of a particular replay asset by a particular user within gaming platform105may result in automated execution of the particular set of in-game operations on behalf of the particular user. For example, activation of the particular replay asset by the particular user within gaming platform105may result in automated execution of the particular set of in-game operations on behalf of the particular user such that a particular user game state (e.g., the current user game state) for the particular user may be advanced to a particular subsequent user game state for the particular user. In some implementations, individual in-game operations may correspond to user-performed actions, including but not limited to user-performed movement, user-performed selections, user-performed waiting periods, and/or other actions performed by users. In some implementations, activation may require ownership of one or more rights pertaining to a particular replay asset, including but not limited to usage rights and/or ownership rights.

By way of non-limiting example,FIG. 3Aillustrates an in-game operation30athat may be performed by in-game character30in a topography31that includes a set of objects, the set of objects including a first object31a, a second object31b, a third object31c, a fourth object31d, a fifth object31e, and a sixth object31f. In-game operation30amay be replayed by another user controlling another character, as described in this disclosure. As depicted, in-game character may be located on top of first object31aprior to performing in-game operation30a. In-game operation30amay be associated with timing information, such as a timestamp (here, the timestamp is t=0). In-game operation30amay include a particular movement (for example a jump) in a particular heading “a” (for example heading α0). In some implementations, in-game operation30amay include a separate step of positioning in-game character according to heading α0, i.e., facing in that direction. In some implementations, in-game operation30amay define the particular movement in a manner that includes the heading information. For example, the result of performing in-game operation may be that in-game character30is located on top of second object31b(shown inFIG. 3B). Performing the wrong movement, or performing the movement in the wrong direction may result in in-game character30being located elsewhere than on top of second object31b, such as near the bottom of second object31b, which may result in an immediate and fiery death of in-game character30(this is not shown).

By way of non-limiting example,FIG. 3Billustrates a set of in-game operations that may be performed by in-game character30in topography31. The set of in-game operations may follow in-game operation30adepicted inFIG. 3A. The set of in-game operations inFIG. 3Bmay include an in-game operation30b(associated with timestamp t=t1and heading α=α1), an in-game operation30c(associated with timestamp t=t2and heading α=α2), an in-game operation30d(associated with timestamp t=t3and heading α=α3), and an in-game operation30e(associated with timestamp t=t4and heading α=α4). A set of in-game operations may form a sequence of in-game operations. The result of performing the set of in-game operations inFIG. 3Bmay be that in-game character30is sequentially positioned on the tops of objects in topography31, ending on top of sixth object31f(in-game character30in end-position not shown inFIG. 3B). In some cases, the timing of certain operations may matter. For example, in-game character30may need to wait and/or duck to avoid a threat or hazard at some point, before proceeding with the next in-game operation in a set of in-game operations.

Referring toFIG. 1, executing a set of in-game operations automatically may include performing, during an automation period, particular in-game actions and/or in-game operations within gaming platform105by a particular in-game character associated with a particular user (such as a user character). The particular user may have control over other in-game actions and/or in-game operations performed by the in-game character before and after the automation period. For example, the particular in-game character may be a user-controlled character that is controlled by the particular user before and after the automation period. During the automation period, system100may control the same character such that the particular user at least temporarily does not control the same character. In some implementations, the particular user temporarily yields control over the character, e.g., until completion of the automation period. In some implementations, the automation period may span the period from the first timestamp in the set of in-game operations to the last timestamp in the set of in-game operations. For example, assuming a particular set of in-game operations includes the in-game operations described in relation toFIGS. 3A-3B, the automation period associated with the particular set of in-game operations may span the period from t=0 to t=t4, during which time in-game character30moves from the top of first object31ato the top of sixth object31f.

Referring toFIG. 1, in some implementations, executing a particular set of in-game operations automatically may occur responsive to a verification verifying a particular user has ownership of, e.g., the usage rights pertaining to the particular replay asset.

Request receiving component110may be configured to receive requests from users for activations of replay assets. Activation of a replay asset by a particular user may result in automated execution of the corresponding set of in-game operations on behalf of the particular user. In some implementations, a particular user may request activation of a replay asset for another user.

Execution component112may be configured to execute sets of in-game operations, e.g., as requested through requests received by request receiving component110. In some implementations, execution component112may be configured to execute sets of in-game operations automatically responsive to activations of replay assets. In some implementations, execution component112may be configured to execute sets of in-game operations automatically such that a particular user game state for a particular user is advanced to a particular subsequent user game state.

Verification performance component114may be configured to perform verifications pertaining to the use and/or activation of replay assets. For example, verification performance component114may be configured to perform a verification whether a particular user has the ownership of the usage rights pertaining to a particular replay asset. In some implementations, one or more verifications may be required prior to execution by execution component112. In some implementations, an implementation of a verification may be based on how the replay assets are stored and/or traded. For example, in some implementations, if replay assets are managed in user inventories within gaming platform105, a verification of ownership may be implemented as a verification that a particular replay asset is included in a particular user inventory. For example, in some implementations, if replay assets are licensed by a creating user to other users, a verification of ownership of usage rights may be implemented as a verification that a particular replay asset is licensed to the particular user requesting its activation. For example, in some implementations, if ownership of replay assets is recorded within blockchain111, a verification of ownership may be implemented as a verification that a particular replay asset includes a particular user's address as its ownership address. For example, in some implementations, if replay assets are licensed by a creating user to other users through blockchain111, a verification of ownership of usage rights may be implemented as a verification that a particular replay asset is licensed to the particular user requesting its activation, e.g. by verifying the particular replay asset includes the particular user's address as one of its licensee addresses.

Registration component116may be configured to register assets, including but not limited to replay assets, on a distributed blockchain, including but not limited to blockchain111. Individual replay assets may be associated with an individual address of a user that has ownership of the usage rights pertaining to the individual replay asset. In some implementations, a verification by verification performance component114may include a verification whether the individual address associated with an individual replay asset is owned by the particular user attempting to activate the particular individual replay asset. In some implementations, a transfer of the ownership of the usage rights pertaining to a particular replay asset may include a transaction that is registered on blockchain111and/or a change of the individual address associated with the particular replay asset.

By way of non-limiting example,FIG. 4Aillustrates a blockchain111athat implements a blockchain including a block0, a block1, and a block2. As time progresses, more blocks may be added to blockchain111a. The blocks within blockchain111aare ordered. In block0, three assets (indicated by a capital “A”) are generated and/or assigned to three users or participants: a first asset is assigned to user i (Ui), a second asset is assigned to user j (Uj), and a third asset is assigned to user k (Uk). These assets may be individual tokens manifested, deployed, and/or instantiated through an asset creating component similar to asset creating component108(seeFIG. 1). Block1is connected to block0(as indicated by a link40a), for example by including an address of block1in block0, or vice versa. Likewise, block1is connected to block2, as indicated by a link40b.

In block1, one asset (labeled Ax) is generated and/or assigned to user q (Uq), for example by associating an address of user q to asset Ax. For example, the asset in block1may be an individual replay asset created by an asset creating component similar to asset creating component126(seeFIG. 1). Replay asset Ax may include and/or refer to a set of in-game operations that are replayable in gaming platform105(not shown). Additionally, block1includes two transactions (indicated by a capital “T”): a first transaction from user i to user j, and a second transaction from user j to user k. Block2includes a first transaction from user j to user m, and a second transaction from user j to user n. In some implementations, based on the contents of the blocks, any user of blockchain111amay determine the current assets of blockchain111a, and the balances of any user. In some implementations, the balance of a particular user may be verified prior to adding a transaction that reduces that particular user's balance. For example, an individual user may not be allowed to transfer assets the individual user does not own.

By way of non-limiting example,FIG. 4Billustrates a blockchain111bthat includes the same blocks as blockchain111aofFIG. 4A, plus additional blocks (block3, block4, block5) that have been appended to the blockchain. Block3may be connected to block2(as indicated by a link40c), block4may be connected to block3(as indicated by a link40d), and block5may be connected to block4(as indicated by a link40e). In block3, a smart contract41(indicated by a capital “C”) is posted. For example, smart contract41may have been generated to implement a way to license usage of replay asset Ax to other users. InFIG. 4B, a function call to a function defined by smart contract41(e.g., to request activation of replay asset Ax) may be depicted and/or implemented as a transaction (e.g., the function may be invoked in exchange for consideration). Smart contract41may have been posted to blockchain111bby a component similar to registration component116(shown inFIG. 1). Referring toFIG. 4B, for example, smart contract41may include or refer to replay asset Ax and record that replay asset Ax is currently owned by user q (Uq). In block4, one asset is generated and/or assigned to user p (Up). Additionally, block4includes a transaction (indicated by a capital “T”): a transaction from user i to user n. For example, the transaction may represent a purchase of a first virtual item by user n. Additionally, block4includes a transaction from user q to the same smart contract as depicted in block3. For example, the transaction may represent user q requesting an activation of replay asset Ax in accordance with the set of in-game instructions included in replay asset Ax. Block5includes two transactions (indicated by a capital “T”): a first transaction of ownership of smart contract41from old owner user q to new owner user p, and a second transaction may represent user p requesting another activation of replay asset Ax in accordance with the set of in-game instructions included in replay asset Ax. For example, the first activation (responsive to the transaction in block4) may operate on an in-game character controlled by user q. For example, the second activation (responsive to the transaction in block5) may operate on an in-game character controlled by user p.

Referring toFIG. 1, sale component118may be configured to receive information reflecting sales of assets, including but not limited to sales of replay assets. For example, sale component118may be configured to receive information reflecting the sale of a particular replay asset from a first user to a second user, or from an online store to a purchasing user. In some implementations, response to such a sale, the particular replay asset may have been added to the second user inventory associated with the second user. Execution performance component120may be configured to perform automated execution of the particular set of in-game operations (corresponding to the particular replay asset that has been sold by the first user to the second user) such that a current user game state for the second user is advanced to a subsequent user game state for the second user within gaming platform105, responsive to a request by the second user to activate the particular replay asset. In some implementations, completion of a sale of a replay asset (e.g., from a creating user to a purchasing user, or from gaming platform105to a purchasing user) may be conditioned on the purchasing user achieving a measurable goal through activation of the particular replay asset. For example, if the purchasing user fails to reach the particular location as intended by activating the particular replay asset, the sale may be reverted and/or otherwise canceled.

By way of non-limiting example,FIGS. 3C-3Dillustrate a sequence of in-game operations that are replayed by a particular user controlling a particular in-game character33. As depicted, in-game character33is located in the same topography31as shown inFIG. 3A, on the top of first object31a, at a time referred to with timestamp t=tx. The current user game state for the second user includes in-game character33being located on the top of first object31a. Assume in-game character33is controlled by a second user who wishes to reach the top of sixth object31fwith in-game character33. Perhaps the second user is having trouble reaching this goal manually, by directly and personally controlling the movement of in-game character33. Assume the second user who has purchased a particular replay asset that includes the set of in-game operations described in relation toFIGS. 3A-3B. Upon a request by the second user to activate the particular replay asset, a particular set of in-game operations is executed automatically on behalf of the second user such that the current user game state for the second user is advanced to a subsequent user game state as shown inFIG. 3D, where in-game character has reached the top of sixth object31f. Intermediate steps and/or moments betweenFIG. 3CandFIG. 3Dmay or may not be shown to the second user. Automatic execution of the particular set of in-game operations may occur during an automation period that spans from timestamp t=txto timestamp t=tx+n, where n correspond to a combination of the number of movements, operations, and wait periods included in the particular set of in-game operations. After this automation period, control of in-game character33may be returned to the second user.

Assembly component122may be configured to create sets of in-game operations by users123, including but not limited to the creating user. For example, the creating user may record a sequence of in-game operations in real-time, as the creating user performs the in-game operations using a particular user character that is controlled by the creating user. In some implementations, assembly component122may be configured to allow editing and/or modification of sets of in-game operations, for example through an editor interface. For example, a creating user may modify a recorded sequence of in-game operations to facilitate future replay by himself and/or other users. In some implementations, assembly component122may be configured to allow editing and/or modification of purchased sets of in-game operations. For example, a purchasing user of a purchased replay asset may modify the sequence of in-game operations to facilitate future replay by himself and/or other users, and/or improve the replay asset. In some implementations, the purchasing user may be able to sell the modified replay asset to other users.

Asset receiving component124may be configured to receive sets of in-game operations from users123, including but not limited to the creating user, other users, and/or stakeholders of gaming platform105.

Asset creating component126may be configured to create replay assets. In some implementations, asset creating component126may be configured to create replay assets such that the created replay assets include and/or refer to received sets of in-game operations (e.g., received through asset receiving component124). In some implementations, assets including replay assets may be created by and/or within gaming platform105. For example, in some implementations, as an in-game challenge is designed, a corresponding asset to meet that challenge may be created.

In some implementations, server(s)102, client computing platform(s)104, and/or external resources128may be operatively linked via one or more electronic communication links. For example, such electronic communication links may be established, at least in part, via one or more networks13, including but not limited to the Internet and/or other networks. It will be appreciated that this is not intended to be limiting, and that the scope of this disclosure includes implementations in which server(s)102, client computing platform(s)104, and/or external resources128may be operatively linked via some other communication media.

A given client computing platform104may include one or more processors configured to execute computer program components. The computer program components may be configured to enable an expert or user associated with the given client computing platform104to interface with system100and/or external resources128, and/or provide other functionality attributed herein to client computing platform(s)104. By way of non-limiting example, the given client computing platform104may include one or more of a desktop computer, a laptop computer, a handheld computer, a tablet computing platform, a NetBook, a Smartphone, a smart watch, a gaming console, and/or other computing platforms.

External resources128may include sources of information outside of system100, external entities participating with system100, and/or other resources. In some implementations, some or all of the functionality attributed herein to external resources128may be provided by resources included in system100.

Server(s)102may include electronic storage130, one or more processors132, and/or other components. Server(s)102may include communication lines, or ports to enable the exchange of information with a network and/or other computing platforms. Illustration of server(s)102inFIG. 1is not intended to be limiting. Server(s)102may include a plurality of hardware, software, and/or firmware components operating together to provide the functionality attributed herein to server(s)102. For example, server(s)102may be implemented by a cloud of computing platforms operating together as server(s)102.

Electronic storage130may comprise non-transitory storage media that electronically stores information. The electronic storage media of electronic storage130may include one or both of system storage that is provided integrally (i.e., substantially non-removable) with server(s)102and/or removable storage that is removably connectable to server(s)102via, for example, a port (e.g., a USB port, a firewire port, etc.) or a drive (e.g., a disk drive, etc.). Electronic storage130may include one or more of optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drive, floppy drive, etc.), electrical charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drive, etc.), and/or other electronically readable storage media. Electronic storage130may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and/or other virtual storage resources). Electronic storage130may store software algorithms, information determined by processor(s)132, information received from server(s)102, information received from client computing platform(s)104, and/or other information that enables server(s)102to function as described herein.

Processor(s)132may be configured to provide information processing capabilities in server(s)102. As such, processor(s)132may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information. Although processor(s)132is shown inFIG. 1as a single entity, this is for illustrative purposes only. In some implementations, processor(s)132may include a plurality of processing units. These processing units may be physically located within the same device, or processor(s)132may represent processing functionality of a plurality of devices operating in coordination. Processor(s)132may be configured to execute components108,110,112,114,116,118,120,122,124, and/or126, and/or other components. Processor(s)132may be configured to execute components108,110,112,114,116,118,120,122,124, and/or126, and/or other components by software; hardware; firmware; some combination of software, hardware, and/or firmware; and/or other mechanisms for configuring processing capabilities on processor(s)132. As used herein, the term “component” may refer to any component or set of components that perform the functionality attributed to the component. This may include one or more physical processors during execution of processor readable instructions, the processor readable instructions, circuitry, hardware, storage media, or any other components.

It should be appreciated that although components108,110,112,114,116,118,120,122,124, and/or126are illustrated inFIG. 1as being implemented within a single processing unit, in implementations in which processor(s)132includes multiple processing units, one or more of components108,110,112,114,116,118,120,122,124, and/or126may be implemented remotely from the other components. The description of the functionality provided by the different components108,110,112,114,116,118,120,122,124, and/or126described below is for illustrative purposes, and is not intended to be limiting, as any of components108,110,112,114,116,118,120,122,124, and/or126may provide more or less functionality than is described. For example, one or more of components108,110,112,114,116,118,120,122,124, and/or126may be eliminated, and some or all of its functionality may be provided by other ones of components108,110,112,114,116,118,120,122,124, and/or126. As another example, processor(s)132may be configured to execute one or more additional components that may perform some or all of the functionality attributed below to one of components108,110,112,114,116,118,120,122,124, and/or126.

FIG. 2illustrates a method200for using re-playable in-game operations to reach particular user game states in an online gaming platform, in accordance with one or more implementations. The operations of method200presented below are intended to be illustrative. In some implementations, method200may be accomplished with one or more additional operations not described, and/or without one or more of the operations discussed. Additionally, the order in which the operations of method200are illustrated inFIG. 2and described below is not intended to be limiting.

In some implementations, method200may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information). The one or more processing devices may include one or more devices executing some or all of the operations of method200in response to instructions stored electronically on an electronic storage medium. The one or more processing devices may include one or more devices configured through hardware, firmware, and/or software to be specifically designed for execution of one or more of the operations of method200.

An operation202may include managing user inventories for users of the online gaming platform. The users may include a creating user and a first user. The user inventories may include a creating user inventory associated with the creating user and a first user inventory associated with the first user. The creating user inventory may include a replay asset that includes and/or refers to a set of in-game operations. The set of in-game operations may be provided by the creating user. Activation of the replay asset by a particular user within the online gaming platform results in automated execution of the set of in-game operations on behalf of the particular user such that a particular current user game state for the particular user may be advanced to a particular subsequent user game state for the particular user. The activation may require ownership of usage rights pertaining to the replay asset. Operation202may be performed by one or more hardware processors configured by machine-readable instructions including a component that is the same as or similar to management component108, in accordance with one or more implementations.

An operation204may include receiving a request, from the first user, for activation of the replay asset by the first user. The activation of the replay asset by the first user may result in automated execution of the set of in-game operations on behalf of the first user. Operation204may be performed by one or more hardware processors configured by machine-readable instructions including a component that is the same as or similar to request receiving component110, in accordance with one or more implementations.

An operation206may include executing the set of in-game operations automatically such that a first current user game state for the first user is advanced to a first subsequent user game state for the first user within the online gaming platform, responsive to the activation of the replay asset as requested by the first user. Operation206may be performed by one or more hardware processors configured by machine-readable instructions including a component that is the same as or similar to execution component112, in accordance with one or more implementations.

Although the present technology has been described in detail for the purpose of illustration based on what is currently considered to be the most practical and preferred implementations, it is to be understood that such detail is solely for that purpose and that the technology is not limited to the disclosed implementations, but, on the contrary, is intended to cover modifications and equivalent arrangements that are within the spirit and scope of the appended claims. For example, it is to be understood that the present technology contemplates that, to the extent possible, one or more features of any implementation can be combined with one or more features of any other implementation.