Collaborative game tasks are sometimes used in board games to increase player engagement, as such tasks are inherently social. Of course, such tasks bear more than some resemblance to real-world collaborative tasks, which tend to be managed through project-management processes including monitoring and controlling task activities.
Online games, including massively multiplayer online (MMO) games, tend to have a large number of players who can be described as “casual” (as opposed to “hardcore”). Such players are willing to devote only a small amount of their time and resources to game play and would be put off by any collaborative game task that resembled a real-world project.
Consequently, creating collaborative game tasks for casual online gamers continues to be an ongoing area of research and experimentation for the designers of online games.
In an example embodiment, a processor-executed method is described for engaging players in a massively multiplayer online (MMO) game. According to the method, software at a website hosting an MMO game creates a team (or group) to perform a collaborative game task in the MMO game. Each player on the team is assigned from a queue of players who share one or more attributes. The collaborative game task is composed of a plurality of individual game tasks. Each player on a team is assigned an individual game task by the software. The software provides a game reward to a player after the player has satisfactorily completed less than all of the individual game task assigned to the player. The software determines that the team has satisfactorily completed the collaborative game task, according to the game mechanics associated with the collaborative game task. Then the software provides a game reward to each player on the team.
In another example embodiment, an apparatus is described, namely, computer-readable storage media that persistently store a program for engaging players in an MMO game. The program might be part of the software at a website hosting the MMO game. The program creates a team (or group) to perform a collaborative game task in the MMO game. Each player on the team is assigned from a queue of players who share one or more attributes. The collaborative game task is composed of a plurality of individual game tasks. Each player on the team is assigned an individual game task by the program. The program provides a game reward to a player after the player has satisfactorily completed less than all of the individual game task assigned to the player. The program determines that a team has satisfactorily completed the collaborative game task, according to the game mechanics associated with the collaborative game task. Then the program provides a game reward to each player on the team.
Another example embodiment also involves an apparatus for engaging players in an MMO game, e.g., a server at a website hosting an MMO game. The apparatus includes one or more processors and memory storing processor-executable instructions. The instructions might be part of the software at a website hosting the MMO game. The instructions create a team (or group) to perform a collaborative game task in the MMO game. Each player on the team is assigned from a queue of players who share one or more attributes. The collaborative game task is composed of a plurality of individual game tasks. Each player on the team is assigned an individual game task by the program. The instructions provide a game reward to a player after the player has satisfactorily completed less than all of the individual game task assigned to the player. The instructions determine that a team has satisfactorily completed the collaborative game task, according to the game mechanics associated with the collaborative game task. Then the instructions provide a game reward to each player on the team.
Other aspects and advantages of the inventions will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate by way of example the principles of the inventions.
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the exemplary embodiments. However, it will be apparent to one skilled in the art that the example embodiments may be practiced without some of these specific details. In other instances, process operations and implementation details have not been described in detail, if already well known.
The personal computing device 102 might be (a) a laptop or other personal computer or (b) a mobile device such as a smartphone, (e.g., an iPhone, Blackberry, Android, etc.), a tablet computer (e.g., an iPad), etc. In an example embodiment, each of the websites 103 and 106 might be composed of a number of servers connected by a network (e.g., a local area network (LAN) or a WAN) to each other in a cluster or other distributed system which might execute cloud platform software. The servers in website 103 and 106 might also be connected (e.g., by a storage area network (SAN)) to persistent storages 105 and 107, respectively. In an example embodiment, persistent storages 105 and 107 might include a redundant array of independent disks (RAID).
Persistent storage 105 might be used to store algorithms and data related to an MMO game and its players, including data about the players received by website 103 from website 106 (e.g., through an application programming interface (API) exposed by website 106). In an example embodiment, some of the data from persistent storage 105 might be cached in memory cache 104 in volatile memory on servers on website 103 (e.g., using (a) an in-memory database or main memory database system (MMDB) or (b) a hybrid in-memory database that also uses persistent storage) in order to improve performance. Persistent storage 107 might be used to store data (including content) associated with a profile and/or stream for members of a social network (or social graph), e.g., users who are associated with each other through access-control lists (ACLs).
As indicated above, personal computing device 102 might be a laptop or other personal computer. In that event, personal computing device 102 and the servers in website 103 and 106 might include (1) hardware consisting of one or more microprocessors (e.g., from the x86 family or the PowerPC family), volatile storage (e.g., RAM), and persistent storage (e.g., a hard disk or solid-state drive), and (2) an operating system (e.g., Windows, Mac OS, Linux, Windows Server, Mac OS Server, etc.) that runs directly or indirectly (e.g., through virtualization software) on the hardware. Or the operating system for the servers might be replaced by a hypervisor or other virtualization software. Alternatively, personal computing device 102 might be a smartphone, tablet computer, or other mobile device that includes (1) hardware consisting of one or more low-power microprocessors (e.g., from the ARM family), volatile storage (e.g., RAM), and persistent storage (e.g., flash memory such as microSD) and (2) an operating system (e.g., Symbian OS, RIM BlackBerry OS, iPhone OS, Palm webOS, Windows Mobile, Android, Linux, etc.) that runs on the hardware.
Also in an example embodiment, personal computing device 102 might include a web browser as an application program or part of an operating system. Examples of web browsers that might execute on personal computing device 102 if it is a laptop or other personal computer include Internet Explorer, Mozilla Firefox, Safari, and Google Chrome. Examples of browsers that might execute on personal computing device 102 if it is a smartphone, tablet computer, or other mobile device include Safari, Mozilla Firefox, Android Browser, and Palm webOS Browser. It will be appreciated that users of personal computing device 102 might use browsers to communicate with software running on the servers at website 103 and at website 106. Alternatively, users of personal computing device 102 might use other application programs to communicate with software running on the servers at website 103 and at website 106. For example, if the personal computing device 102 is a smartphone, tablet computer, or other mobile device, users might use an app or a hybrid app (e.g., an app written in Objective C or Java that includes embedded HTML5) to communicate with software running on the servers at website 103 and at website 106. It will be appreciated that an application program for a mobile device is often referred to as an “app”.
Returning to
In
As depicted in
In operation 301, the software creates a team. In an example embodiment, teams of a specified size might be created from queues of players (1) who have opted to play the MMO game (e.g., by clicking on a control in a game graphical user interface (GUI)), and (2) who share similar attributes, such as age, gender, language, geo-location (e.g., as determined by IP address, device GPS coordinates, etc.), player level (e.g., greater than 72, as measured in terms of experience points or in terms of points in a reputation system based on both experience and social activity with other players), and gaming activity (e.g., recently inactive, recently casual, recently active, recently hardcore, etc.). In an example embodiment, the queues might be load balanced, e.g., by the addition of a new queue with attributes similar to an existing queue that has grown too long. Also, when assigning players to queues, the software might make a determination as to whether players share similar attributes using clustering analysis, e.g., clustering analysis that depends on a distance between objects (where the objects are players), such as connectivity-based clustering or hierarchy clustering. Some or all of the data as to the player attributes might have been received from a website hosting a social network, e.g., through an application programming interface (API) exposed by that website, in an example embodiment. Or some or all of the data as to player attributes might have come from player profiles maintained by the software at the website hosting the MMO game, including data received from a website hosting a social network. In an alternative example embodiment, teams might be composed of players with dissimilar attributes, e.g., as determined by clustering analysis. For example, a team might include a player with a low player level and a player with a high player level, if data in the player profiles indicates that both players would enjoy being on such a team.
Also, in an example embodiment, the players on the same queue might not be otherwise connected by a social graph; that is, to say, they might be not be “friends” or “neighbors” (e.g., as determined by an access control list (ACL)) on a social network maintained by a website hosting a social network or the website hosting the MMO game. However, in an alternative example embodiment, all the players on the same queue might also be “friends” or “neighbors” (e.g., as determined by an access control list (ACL)) on a social network. Or the software at the website hosting the MMO game might apply a filter to the player queue to only select players for a team who are “friends” or “neighbors” on a social network. (Similar filters might be used for other attributes such as recency of gaming activity or to avoid players who have already been removed from the team.) In another example embodiment, the team might be composed of “friends” or “neighbors” on a social network without resort to player queues. For example, software at the website hosting the MMO game might facilitate the creation of a team through GUIs that enable a founder of a team to send invitations (e.g., electronic messages) to his/her “friends” or “neighbors” on a social network, e.g., through an API exposed by website hosting the social network or via a messaging protocol.
In an example embodiment, the software performing the operations shown in
In operation 302, the software assigns an individual game task (e.g., dish) to each player on the team. In an example embodiment, the game mechanics of the MMO game might allow a player to purchase completion of an individual game task can with virtual currency or other virtual game resources. For example, a player might use virtual currency to hire a non-player character (NPC) to help with an individual game task. It will be appreciated that such a game mechanic might be attractive to a player who is a casual gamer who has fallen behind in the performance of his/her individual game task but does not want to prevent his/her team from timely completing their collaborative game task.
As depicted in
In operation 401, the software determines that a player has been inactive for a specified period of time (e.g., 11 days). It will be appreciated that the specified period of time depends upon numerous factors, including the game mechanics of the MMO game, current game statistics, player profiles, etc. In other example embodiments, the specified time might be less than 11 days or greater than 11 days. Similarly, in operation 404, the software disbands the team and removes the team from the team queue, if a new player cannot be added to the team from a player queue within a specified period of time (e.g., 2 days). Here again, the specified period of time depends upon numerous factors, including the game mechanics of the MMO game, current game statistics, player profiles, etc. In other example embodiments, the specified time might be less than 2 days or greater than 2 days.
As depicted in
In operation 501, the software creates teams. In an example embodiment, teams of a specified size might be created from queues of players (1) who have opted to play the MMO game (e.g., by clicking on a control in a game graphical user interface (GUI)), and (2) who share similar attributes, such as age, gender, language, geo-location (e.g., as determined by IP address, device GPS coordinates, etc.), player level, and gaming activity. In an example embodiment, the queues might be load balanced, e.g., by the addition of a new queue with attributes similar to an existing queue that has grown too long. When assigning players to queues, the software might make a determination as to whether players share similar attributes using clustering analysis, e.g., clustering analysis that depends on a distance between objects (where the objects are players), such as connectivity-based clustering or hierarchy clustering. Some or all of the data as to the player attributes might have been received from a website hosting a social network, e.g., through an application programming interface (API) exposed by that website, in an example embodiment. Or some or all of the data as to player attributes might have come from player profiles maintained by the software at the website hosting the MMO game, including data received from a website hosting a social network. Here again, in an alternative example embodiment, teams might be composed of players with dissimilar attributes, e.g., as determined by clustering analysis. For example, a team might include a player with a low player level and a player with a high player level, if data in the player profiles indicates that both players would enjoy being on such a team.
Also, in an example embodiment, the players on the same queue might not be otherwise connected by a social graph; that is, to say, they might be not be “friends” or “neighbors” (e.g., as determined by an access control list (ACL)) on a social network maintained by a website hosting a social network or the website hosting the MMO game. However, in an alternative example embodiment, all the players on the same queue might also be “friends” or “neighbors” (e.g., as determined by an access control list (ACL)) on a social network. Or the software at the website hosting the MMO game might apply a filter to the player queue to only select players for a team who are “friends” or “neighbors” on a social network. (Similar filters might be used for other attributes such as recency of gaming activity or to avoid players who have already been removed from the team.) In another example embodiment, the team might be composed of “friends” or “neighbors” on a social network without resort to player queues. For example, software at the website hosting the MMO game might facilitate the creation of a team through GUIs that enable a founder of a team to send invitations (e.g., electronic messages) to his/her “friends” or “neighbors” on a social network, e.g., through an API exposed by website hosting the social network or via a messaging protocol.
In an example embodiment, the software performing the operations shown in
In operation 502, the software assigns an individual game task (e.g., dish) to each player on a team. In an example embodiment, the game mechanics of the MMO game might allow a player to purchase completion of an individual game task can with virtual currency or other virtual game resources. For example, a player might use virtual currency to hire a non-player character (NPC) to help with an individual game task. It will be appreciated that such a game mechanic might be attractive to a player who is a casual gamer who has fallen behind in the performance of his/her individual game task but does not want to prevent his/her team from timely completing their collaborative game task.
In operation 504, the software provides a game reward (e.g., virtual currency, other virtual game resources, experience points, other measure of player level or game status, etc.) to a player after the player has satisfactorily completed less than all of an individual game task (e.g., dish) assigned to the player. In an example embodiment, the reward might be provided after the player has completed a specified percentage (e.g., 50%) of his/her individual game task (e.g., dish). In an alternative example embodiment, the reward might be based on a team goal that has been met, e.g., the preparation and/or serving a specified number of virtual dishes (e.g., 300 hamburgers) or the achievement of a specified state (e.g., player level) by each member of the team.
Dashboard view 901 in
Dashboard view 1001 in
Dashboard view 1101 in
In operation 1, the player clicks on a graphic for a social MMO game, causing browser 1301 to transmit an HTTP request to server software 1302 (e.g., Facebook) for the game's initial web page. In operation 2, server software 1302 (e.g., Facebook) returns an HTML5 and JavaScript (JS) web page consisting of an iFrame (e.g., Facebook “chrome”) and an iFrame HTML tag for the game's initial web page. In operation 3, the browser uses the HTML tag to transmit a request to server software 1303 (e.g., Zynga) for the game's initial web page to display inside the iFrame. The game's initial web page might be an application server page (e.g., PHP 5) or an HTML5 page. In operation 4, the application server page executes on server software 1303 (e.g., Zynga), resulting in requests to databases and other servers as needed to complete generation of the web page, including possibly an HTTP request (not shown) transmitted to an API exposed by server software 1302 (e.g., Facebook). In operation 5, the server software 1303 (e.g. Zynga) returns the game's initial web page (e.g., HTML5 and JS) for the browser to display in the iFrame.
At some point thereafter, in operation 6, the player clicks on a graphic (e.g., representing a graphical user interface or GUI widget) on a game web page (e.g., HTML5 and JS), causing browser 1301 to transmit an HTTP request to server software 1303 (e.g., Zynga), requesting assistance with an individual game task (e.g., requesting a virtual ingredient from the player's friends on a social network, possibly including friends who are not members of the player's team or even presently players of the MMO game). In operation 7, the server software 1303 (e.g. Zynga) returns a web page (e.g., HTML5 and JS) to the browser indicating that the request was received. In operation 8, the server software 1303 (e.g., Zynga) transmits an HTTP request to an API exposed by server software 1302 (e.g., Facebook), posting the request for assistance with an individual game task to the profiles (e.g., through a Facebook notification) and/or streams of the requesting player's friends on the social network managed by server software 1302 (e.g., Facebook). It will be appreciated that in order to access the friends' profiles and/or streams (e.g., using an access token), the server software 1303 (e.g., Zynga) might have earlier obtained permission from the friends, e.g., when they joined the game or other Zynga games. Then in operation 9, server software 1302 (e.g., Facebook) sends a response, e.g., in Java Script Object Notation (JSON), to server software 1303 (e.g., Zynga) describing the success or failure of the posting to each profile and/or stream.
In an alternative example embodiment, the game's initial web page (or some subsequent web page served up by the game) might have an Adobe Flash application (e.g., a Small Web Format or SWF file) embedded in it. In this alternative example embodiment, the user of browser 1301 might thereafter interact with the Adobe Flash application (e.g., its GUI), causing it to interact with the server software 1302 (e.g., Facebook) and the server software 1303 (e.g., Zynga).
At some point thereafter, in operation 4, the player clicks on a graphic (e.g., representing a GUI widget) on a game web page (e.g., HTML5 and JS), causing browser 1301 to transmit an HTTP request to server software 1303 (e.g., Zynga), requesting assistance with an individual game task (e.g., requesting a virtual ingredient from the player's friends on a social network, possibly including friends who are not members of the player's team or even presently players of the MMO game). In operation 5, the server software 1303 (e.g. Zynga) returns a web page (e.g., HTML5 and JS) to the browser indicating that the request was received. In operation 6, the server software 1303 (e.g., Zynga) transmits an HTTP request to an API exposed by server software 1302 (e.g., Facebook), posting the request for assistance with an individual game task to the profiles (e.g., through a Facebook notification) and/or streams of the requesting player's friends on the social network managed by server software 1302 (e.g., Facebook). Here again, it will be appreciated that in order to access the friends' profiles and/or streams (e.g., using an access token), the server software 1303 (e.g., Zynga) might have earlier obtained permission from the friends, e.g., when they joined the game. Then in operation 7, server software 1302 (e.g., Facebook) sends a response, e.g., in JSON, to server software 1303 (e.g., Zynga) describing the success or failure of the posting to each profile and/or stream.
In an alternative example embodiment, the game's initial web page (or some subsequent web page served by the game) might have an Adobe Flash application (e.g., a Small Web Format or SWF file) embedded in it. In this alternative example embodiment, the user of browser 1301 might thereafter interact with the Adobe Flash application (e.g., its GUI), which, in turn, might interact with the server software 1302 (e.g., Facebook) and the server software 1303 (e.g., Zynga).
In an example embodiment, a collaborative game task might be a virtual meal (e.g., at a virtual catering event). Software at a website hosting an MMO game might facilitate the definition of the virtual meal by a player, e.g., by allowing the player to select the virtual dishes that comprise a virtual meal using a graphical user interface (GUI). The software might also allow the player to solicit help completing the virtual dishes in the virtual meal from the player's “friends” or “neighbors” (e.g., as determined by an access control list (ACL)) on a social network maintained by a website hosting a social network or the website hosting the MMO game. For example, the software might allow the player to send a communication (e.g., electronic messages) to a “friend” or “neighbor” on a social network, e.g., through an API exposed by website hosting the social network or via a messaging protocol, asking the “friend” or “neighbor” to complete a virtual dish in the virtual meal, in exchange for a game reward upon completion of all or part of the virtual dish and/or completion of the virtual meal. It will be appreciated that such a collaborative game task will foster social interaction between the player and the player's “friends” and “neighbors” on a social network, e.g., as they encourage (or “nudge”) each other to complete their virtual dishes in order to complete the virtual meal.
Though the disclosure above has focused on MMO games, some or all of the operations described above might be used in a gamification application rather than in an MMO game. It will be appreciated that gamification involves the use of game design techniques, game thinking, and game mechanics to enhance tasks performed in non-game contexts. So for example, some or all of the operations described above might be used in an employee training program involving a collaborative task.
With the above embodiments in mind, it should be understood that the inventions might employ various computer-implemented operations involving data stored in computer systems. These operations are those requiring physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. Further, the manipulations performed are often referred to in terms, such as producing, identifying, determining, or comparing.
Any of the operations described herein that form part of the inventions are useful machine operations. The inventions also relate to a device or an apparatus for performing these operations. The apparatus may be specially constructed for the required purposes, such as the carrier network discussed above, or it may be a general purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.
The inventions can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data, which can thereafter be read by a computer system. Examples of the computer readable medium include hard drives, network attached storage (NAS), read-only memory, random-access memory, CD-ROMs, CD-Rs, CD-RWs, DVDs, Flash, magnetic tapes, and other optical and non-optical data storage devices. The computer readable medium can also be distributed over a network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.
Although example embodiments of the inventions have been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications can be practiced within the scope of the following claims. The operations described above can be ordered, modularized, and/or distributed in any suitable way. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the inventions are not to be limited to the details given herein, but may be modified within the scope and equivalents of the following claims. In the following claims, elements and/or steps do not imply any particular order of operation, unless explicitly stated in the claims or implicitly required by the disclosure.
This application claims priority to Provisional Application Ser. No. 61/674,756, entitled “Rewarding Participating Players on a Collaborative Game Task in an Online Game”, filed on Jul. 23, 2012, and Provisional Application Ser. No. 61/674,808, entitled “Replacing Players in a Collaborative Game Task in an Online Game”, also filed on Jul. 23, 2012. This application is related to application Ser. No. ______, Attorney Docket No. ZYNP026, entitled “Replacing Players in a Collaborative Game Task in an Online Game”, which was contemporaneously filed. The disclosures of all of the above applications are incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
61674756 | Jul 2012 | US | |
61674808 | Jul 2012 | US |