The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
The illustrative embodiments described hereafter provide a mechanism for generating virtual world event notifications from within a persistent world game. As such, the illustrative embodiments may be implemented in a distributed data processing environment in which multiple computing devices are utilized along with one or more data networks. Accordingly,
With reference now to the figures,
In the depicted example, servers 102, 104, and 106 are connected to network 120 along with storage unit 108. In addition, clients 112, 114, and 116 are also connected to network 120. These clients 112, 114, and 116 may be, for example, personal computers, network computers, or the like. In the depicted example, server 102 may provide data, such as boot files, operating system images, and applications to the clients 112, 114, and 116. In this instance, clients 112, 114, and 116 are clients to server 102 in the depicted example. Distributed data processing system 100 may include additional servers, clients, and other devices not shown.
More particularly, distributed data processing system 100 may provide a massively multiplayer online game environment. Server 102 may provide a game server for maintaining a persistent virtual world for clients 112, 114, 116. A persistent virtual world is a representation of an environment with which players interact. The virtual world is persistent because the environment continues to exist and evolve even when a given player is not logged in. Server 102 may run game server software and maintain a database in storage 108 to track the states of objects, structures, and characters in the persistent virtual world.
Clients 112, 114, 116 may run game client software that a player uses to interact with the persistent virtual world. Clients 112, 114, 116 may render a two-dimensional or three-dimensional representation of the persistent virtual world, although clients 112, 114, 116 may also represent the virtual world using text, as in earlier multi-user dungeons (MUDs). The player typically interacts with the virtual world on behalf of, or from the perspective of, the player's character. In three-dimensional game environments, the player's character is represented by a three-dimensional player model. A significant draw of three-dimensional multiplayer online games is the ability to customize the appearance of the player model, which is also referred to as an “avatar.” The players may initially customize the appearance of the player model by selecting facial features, body style, hair color, hair style, facial hair, and the like. Throughout the game experience, the player model may evolve, just as the virtual world itself evolves. For example, the player may add armor, weapons, clothing, functional enhancements, or companions, such as pets.
The player is considered online when the player is logged into the game server through a game client and interacting with the persistent virtual world on a regular basis. Conversely, a player is considered offline when the player is not logged into the game server through a game client. While online, players may interact with the virtual world through commands, keystrokes, or mouse clicks. For example, a common user interface for massively multiplayer online role playing games is the WASD interface, where the virtual world is rendered from the perspective of the player's character and the “W” key moves the character forward, the “A” key turns the character left, the “S” key moves the player backward, and the “D” key moves the player right. Other user interfaces may use the cursor keys, mouse look, a top-down third-party perspective, a chase camera perspective, or other known interface techniques.
Whenever a player character interacts with the virtual world, an event is generated and sent to the game server, e.g., server 102. For instance, if a player at client 112 casts a spell on the character of the player at client 114, either a healing spell or an attack, an event is generated at client 112 and sent to server 102. Server 102 then generates an event and sends it to client 114. Server 102 also keeps track of the position, orientation, and status of each structure, character, and item. The evolution of the virtual world is the result of events. A database contains the current state of the virtual world. The events cause changes to the virtual world and, thus, the database. The role of the game client is essentially to represent these events graphically (or textually) to allow the player to monitor for events that are relevant to that player's character and to perform appropriate actions by interacting with the game client.
In one illustrative embodiment, server 104 runs a notification server. Each player may configure a player agent with a set of offline rules. The player agent may run on game server 102, notification server 104, or one of clients 112, 114, 116. The player agent monitors the events and applies the set of offline rules. If an event occurs that matches an offline rule, notification server 104 generates a message. Notification server 104 then sends the message to the offline player. The message may be, without limitation, an electronic mail message, an instant message, a voice message, or a wireless phone message.
In another exemplary embodiment, server 106 may run a Web server application, which provides Web-based user interfaces for configuring rules or reading or composing messages for notification server 104. Thus, a player may configure the set of offline rules while at work through a Web interface without the need for a heavy, graphics-intensive game client. Alternatively, a player may configure offline rules through the game client itself or a specialized client application.
While the depicted example shows the game server, the notification server, and the Web server as separate physical devices, these servers, or various combinations of these servers, may actually be server applications running on the same physical device. For example, the game server and notification server may both run on server 102 and the Web server may run on server 104. Alternatively, the notification functionality may be integrated within the game server on server 102.
In the depicted example, distributed data processing system 100 is the Internet with network 120 representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, governmental, educational and other computer systems that route data and messages. Of course, the distributed data processing system 100 may also be implemented to include a number of different types of networks, such as for example, an intranet, a local area network (LAN), a wide area network (WAN), or the like. As stated above,
With reference now to
In the depicted example, data processing system 200 employs a hub architecture including north bridge and memory controller hub (NB/MCH) 202 and south bridge and input/output (I/O) controller hub (SB/ICH) 204. Processing unit 206, main memory 208, and graphics processor 210 are connected to NB/MCH 202. Graphics processor 210 may be connected to NB/MCH 202 through an accelerated graphics port (AGP).
In the depicted example, local area network (LAN) adapter 212 connects to SB/ICH 204. Audio adapter 216, keyboard and mouse adapter 220, modem 222, read only memory (ROM) 224, hard disk drive (HDD) 226, CD-ROM drive 230, universal serial bus (USB) ports and other communication ports 232, and PCI/PCIe devices 234 connect to SB/ICH 204 through bus 238 and bus 240. PCI/PCIe devices may include, for example, Ethernet adapters, add-in cards, and PC cards for notebook computers. PCI uses a card bus controller, while PCIe does not. ROM 224 may be, for example, a flash binary input/output system (BIOS).
HDD 226 and CD-ROM drive 230 connect to SB/ICH 204 through bus 240. HDD 226 and CD-ROM drive 230 may use, for example, an integrated drive electronics (IDE) or serial advanced technology attachment (SATA) interface. Super I/O (SIO) device 236 may be connected to SB/ICH 204.
An operating system runs on processing unit 206. The operating system coordinates and provides control of various components within the data processing system 200 in
As a server, data processing system 200 may be, for example, an IBM® eServer™ pSeries® computer system, running the Advanced Interactive Executive (AIX®) operating system or the LINUX® operating system (eServer, pSeries and AIX are trademarks of International Business Machines Corporation in the United States, other countries, or both while LINUX is a trademark of Linus Torvalds in the United States, other countries, or both). Data processing system 200 may be a symmetric multiprocessor (SMP) system including a plurality of processors in processing unit 206. Alternatively, a single processor system may be employed.
Instructions for the operating system, the object-oriented programming system, and applications or programs are located on storage devices, such as HDD 226, and may be loaded into main memory 208 for execution by processing unit 206. The processes for illustrative embodiments of the present invention may be performed by processing unit 206 using computer usable program code, which may be located in a memory such as, for example, main memory 208, ROM 224, or in one or more peripheral devices 226 and 230, for example.
A bus system, such as bus 238 or bus 240 as shown in
Those of ordinary skill in the art will appreciate that the hardware in
Moreover, the data processing system 200 may take the form of any of a number of different data processing systems including client computing devices, server computing devices, video game consoles, a tablet computer, laptop computer, telephone or other communication device, a personal digital assistant (PDA), or the like. In some illustrative examples, data processing system 200 may be a portable computing device which is configured with flash memory to provide non-volatile memory for storing operating system files and/or user-generated data, for example. Essentially, data processing system 200 may be any known or later developed data processing system without architectural limitation.
Game clients 302 may be, for example, personal computers or video game consoles. Personal computers, as referred to herein, may include desktop computers, laptop computers, or any other computing device that is capable of running a game client application. A video game console is a specialized computing device that is used to play video games. The game software itself may be available on a compact disc (CD) or digital video disc (DVD). Earlier game machines used cartridges containing read only memory (ROM) chips. Although video game consoles may be powered by similar processor chips as desktop computers, the hardware is under the entire control of the respective manufacturer, and the software is specific to the machine's capabilities. Video game consoles may also include hand-held video game devices, which are self-contained devices with audio capabilities and displays built-in.
As the persistent virtual game world evolves through interaction by the players and other events, such as scripted actions by non-player characters (NPCs), public game server 312 observes the interactions and may generate events. Public game server 312 then records the results of the events in information/game database 322. Public game server 312 may also broadcast events to all of the online players affected by the events within game clients 302. In most current implementations, the persistent virtual game world is divided into “zones.” Thus, while there may be over 2,000 players online at a given time, there may only be 200 players in a particular zone. Therefore, when an event occurs in that zone, such as a player attacking a non-player merchant character, public game server 312 may broadcast the event to only the players in that zone. A person or ordinary skill in the art will recognize that the manner in which game events are distributed to online player clients is not a focus of this disclosure.
In current massively multiplayer online games, offline player presence is severely limited. At best, a player may place an item up for auction and the auction house may sell the item on behalf of the player while the player is offline. However, offline player activity is limited to only selling items in the auction house and the offline activity must be configured through the game client while the player is online. In other implementations, the player must leave his or her client device logged in to allow the character to sell an item, for instance, or to perform any other action. This causes subscribers to feel a sense of loss whenever they are offline. That is, while a player is unable to have an online presence in the virtual game world, she may be missing critical events. For example, a player may return home from a long walk in the park to find out that her home city in the virtual world has been overrun by the enemy.
In accordance with an exemplary embodiment, player agents 332, 334, 336 use offline player rules 342, 344, 346 to monitor for events that are relevant to particular offline players. For example, each one of player agents 332, 334, 336 may execute on behalf of an offline player. Player agents 332, 334, 336 may execute, for example, in game clients 302, public game server 312, notification server 314, or combinations thereof. The offline players configure offline player rules 342, 344, 346 to define what types of events are relevant, as well as how, when, and/or where event notifications are to be distributed. For instance, a particular player configures player agent 332 with offline player rules 342. Player agent 332 monitors events observed by and generated by public game server 312 or specific changes to the virtual world persisted to information/game database 322. If an event occurs that satisfies one of the set of offline player rules 342, player agent 332 generates an event notification message. In one exemplary embodiment, if an event satisfies more than one rule, then player agent 332 may combine the resulting event notifications into a single message. Alternatively, the player agent may generate a separate event notification message for each player rule that is triggered.
Notification server 314 may deliver event notification messages to messaging clients 304. Event notification messages may include, without limitation, electronic mail messages, instant messages, voice mail messages, facsimile transmissions, or wireless phone messages. As an example, player agent 332 may compose an electronic mail message containing the event information, and notification server 314 may deliver it to one of message clients 304, through an electronic mail server, using the simple mail transfer protocol (SMTP). As another example, notification server 314 may deliver an event notification message to a group of messaging clients 304 through Internet relay chat (IRC). As yet another example, notification server 314 may deliver an event notification message to a short message service (SMS) client. A person of ordinary skill in the art will recognize that other known messaging techniques may be used.
Messaging clients 304 may be any client devices capable of receiving event notification messages. More particularly, messaging clients 304 may include, without limitation, personal computers, telephone devices, personal digital assistants, push email client devices, set-top television devices, or video game consoles. As an example, an offline player may receive a text message on his wireless telephone notifying him that his base is being attacked by the enemy. As a further example, a particular player may receive an email at work notifying her that a particular non-player character has appeared in the same zone as her character.
In one exemplary embodiment, players may configure offline player rules 342, 344, 346 using the game client applications on game clients 302. That is, the game client software may provide user interfaces for setting offline player rules. For example, a player may indicate whether event notification messages are to be sent to a particular wireless phone number, email address, or instant messaging identification. Offline player rules may also define whether notification messages shall include text, image, or voice, for example. A player may also define what types of events shall trigger event notification.
In another exemplary embodiment, web server 316 may provide Web-based user interfaces for configuring offline player rules 342, 344, 346. Thus, players may configure offline rules while at work using Web clients 306 without the need for a graphics-intensive game client application. Web clients 306 may include, without limitation, personal computers, Web-enabled wireless phone devices, or set-top television devices.
In accordance with another illustrative embodiment, player agents 332, 334, 336 may generate events on behalf of offline players according to offline player rules 342, 344, 346. Players may configure offline player rules 342, 344, 346 with actions to be taken while the player is offline. Thus, the player's character may have a presence within the persistent virtual world even when the player is offline. If an event occurs that matches one of the offline player rules of a given character, the respective player agent may generate one or more events if the offline player rule calls for an action to be taken. The player agent then may send the one or more events to public game server 312 as if the event was generated by a game client for an online character.
In particular embodiments, an offline character may be represented in the persistent virtual game world just as a non-player character is represented. This may actually enhance the game experience, because players may provide interesting game content through the actions taken according to offline player rules. For instance, players may contribute to the persistent virtual world even while offline by providing offline player rules that offer quests to online characters. Offline players may dance for a few coins or upgrade armor for a price, for example. Alternatively, offline players may perform scripted actions to add to the overall story of the virtual world. In a sense, through careful configuration of offline player rules, a player's character may become a non-player character (NPC) while the player is offline.
Alternatively, offline players may add, modify, remove, or receive a list of offline player rules using messaging clients 304. When a player issues a message from one of messaging clients 304, notification server 314 may forward the message to the respective player agent 332, 334, 336. In response to appropriate incoming messages, player agents 332, 334, 336 may update offline player rules 342, 344, 346.
The game provider sees an added benefit, because an active community of players will provide a virtual environment that is truly built and shaped by the players. While game providers may still provide non-player characters, quests, expansions, and the like, the game community will be fueled by the imaginations of the subscribers. As a result, the game providers may experience a reduction in the cancellation rate of account memberships.
If a game event received from event monitor 402 matches one of offline player rules 412, rules manager triggers message composer 408 to compose an event notification message. Message composer 408 may simply formulate a text message using a template, for example. In addition, message composer 408 may include in the message an image, such as a still image of the current state of the game or an image of an item, based on the active rule from offline player rules 412. The rules may also include a text message, sound file, or the like to send as the message or attached to the message. This allows the user to customize the message he receives, much like a ring tone may identify a caller. Further, if indicated within the active rule, message composer 408 may perform text-to-speech conversion and output the event notification message as a sound file, telephone call, or voice mail. Message composer 408 then provides the generated message to the notification server.
Message parser 406 receives incoming messages that may add, modify, or remove rules in offline player rules 412. Message parser 406 parses the message according to templates or a predefined syntax, for example. In response to appropriate incoming messages, rules manager 410 updates offline player rules 412. For example, rules manager 410 may add more detailed events, request a still image or short video, etc.
In another illustrative embodiment, rules manager 410 may signal event generator 404 to generate game events on behalf of the offline player. In response to a particular rule being activated from offline player rules 412, or in response to an appropriate incoming message, rules manager 410 may activate event generator 404 to send a game event to the public game server as if the event were generated by an online player's game client.
Rules client window 500 includes a contact information portion 510, a message content portion 520, and a notification type portion 530. In contact information portion 510, the player may indicate whether he or she wishes to receive game event notifications by wireless phone, electronic mail, or instant messenger. The player may provide the contact information in text entry fields 512. As an example, a player may check the “Wireless phone” box and enter a telephone number in the appropriate field. Contact information portion 510 may include more or fewer options depending upon the implementation.
Message contact portion 520 allows a player to indicate whether the message should include a text notification, an image, or voice. In an exemplary implementation, the player may check all three selections. If the “Image” selection is checked, the notification service may provide an image of an item or a screen capture from a game client of a nearby online player, for example. Alternatively, the game server may be configured to generate a low resolution image, for instance. If the “Voice” selection is checked, the notification service may perform text-to-speech conversion and provide the event notification message as a voice message or voice mail. Message contact portion 520 may also include fields to allow the user to specify message text, an image file, or sound file.
Notification type portion 530 allows a player to indicate what types of events should result in a notification message. In the depicted example, the types of notification events include a market price offer to buy an item the player is selling, an offer to sell an item the player has on a wish list, an attack on the player's guild hall, and an attack on the player's character. Notification type portion 530 presents a small number of checkboxes for simplicity; however, a person of ordinary skill in the art will appreciate that the catalogue of possible event types may be quite extensive and will likely include many more event types and more detailed and complicated rules. In an alternative embodiment, notification type portion 530 may include a notification entry interface that allows the player to customize notification types.
In the depicted example, image 712 is of a particular item being offered for sale. However, the image may be any type of image related, or perhaps unrelated, to the event notification. For example, players may offer photographs to be used in character profiles. As another example, image 712 may be an illustration that is reasonably associated with the particular event.
As another example, the image may be a screen capture taken by a nearest online player to the event or by the game server. For instance, if an online character offering the item for sale happens to be looking at the offline player's character when making the offer, the game server may instruct the online character's game client application to take a low resolution screen capture and send the screen capture image to the player agent composing the message. Alternatively, if the offline character's city is attacked, the image may be a screen capture by a nearest online bystander, the offline player character's point of view, or even an attacker, showing the ruin left in the wake of the attack. In this manner, the event notification message may provide significant persistent world information to an offline player through standard communications channels outside the game world.
Reply instructions 820 tell the player how to send a message into the event notification server to perform an offline action responsive to the event. In this example, the player may select “Reply” button 822 and reply to the message with the word “buy” to purchase the item.
The offline player rule customization interface includes rules list portion 1010, “Add” button 1012, “Remove” button 1014, “Edit” button 1016, and “Done” button 1018. The existing rules are listed in rules list portion 1010. Selecting “Add” button 1012 may cause the Web client to generate another interface for entering a specific offline player rule. The interface (not shown for simplicity) for entering a specific offline player rule may be, for example, a simple text entry field. However, given the number of possible rules in a typical massively multiplayer online game, the interface for entering a rule may include radio buttons, check boxes, drop-down menus, and the like.
The player may select a rule in rule list portion 1010 and select “Remove” button 1014 to remove the list from the list. Selecting a rule from rule list portion 1010 and selecting “Edit” button 1016 may generate an interface for entering rule information similar to that described above for adding a rule. When the player is finished adding, removing, and editing rules, the player may select “Done” button 1018 to persist the rules to the offline player agent, which may reside locally on the game client or may reside at the game server or event notification server, as described above.
The player may also select “Command Syntax Help” button 1022 to view a help dialog. Since the number and complexity of the commands may be more than can be remembered by a casual user, the help dialog may present a list of commands and guidelines for the syntax. The help dialog may also include other information, such as frequently asked questions, troubleshooting information, example commands, templates, etc.
In addition, display area 1002 may also present banner advertisement 1020. As stated above, the game provider may use the event notification messages as a vehicle to advertise related products or to sell advertising to partners.
The command editing commands may include “add,” “delete,” “change,” “and “view rules” commands. Thus, the user may compose a message beginning with “<add>” followed by the command to be added, for example. Other commands are possible, such as “fleenow,” “attack,” and so forth, depending on the commands of the game client. Many online persistent world game clients include a command-line interface, although it is usually hidden from the user in the default interface. When message composition is complete, the player may select “Send” button 1112 to send the message to the player agent through the event notification server.
In many current massively multiplayer online role playing games, which have persistent virtual worlds, players must wait for a particular event to happen. For instance, a player may have to battle a certain monster to complete a quest. An artificial intelligence controlled monster is often referred to as a “mob,” which is a term from the MUD era that refers to a “mobile” monster that patrols a set of rooms. Many times, a player knows where the monster will appear, or “spawn”; however, the player may not know when the monster will appear. This leaves an online player in a situation where he must sit and wait, referred to as “camping.” This is often a source of frustration for many MMORPG players.
In accordance with some exemplary embodiments, a player agent may “wake” or “launch” the game client software on the user's client device in response to a particular event.
More particularly, with reference to
At client device 1220, player agent 1222 applies offline player rules 1224 to events received from game server 1210. Player agent 1222 may be a small monitor application running on client device 1220. For example, player agent 1222 may be a terminate-and-stay-ready (TSR) program or other program that runs in the background. Certain offline player rules may instruct player agent 1222 to launch game client software 1226 in response to particular events. For example, consider the following example of an offline player rule:
An offline player may be taking a break to get some work done, answer emails, or shop online, for example. If a significant event happens in the virtual world, the player agent automatically launches the game client for the player, who can then jump right into the action. Thus, the player may wait for particular event to occur in the persistent virtual world without losing precious time in the real world.
Turning to
In the example depicted in
With reference now to
Player agent 1262 applies offline player rules 1264 to events observed at game server 1260. Certain offline player rules may instruct player agent 1262 to launch game client software 1276 at client device 1270 in response to particular events. If an offline player rule instructs player agent 1262 to launch game client 1276, player agent 1262 sends a launch request to launcher component 1272 at client device 1270. Launcher component 1272 may be a small monitor application running on client device 1270. For example, launcher component 1272 may be a terminate-and-stay-ready (TSR) program or other program that runs in the background. Responsive to a launch request being received from player agent 1762, launcher component launches game client software 1276.
Turning to
Player agent 1262 applies offline player rules 1264 to events observed at game server 1260. Certain offline player rules may instruct player agent 1262 to launch game client software 1276 at client device 1270 in response to particular events. If an offline player rule instructs player agent 1262 to launch game client 1276, player agent 1262 may send notification message 1282 to the offline player with instructions for launching the game client software 1276 on client device 1270. Perhaps during the user's offline time, the user is out cleaning the garage or visiting with a next-door neighbor. The user may then receive event notification message 1282 on a messaging device (not shown), such as a wireless phone or personal digital assistant, and return reply message 1284. Reply message 1284 may include a command to launch game client software 1276 on client device 1270.
If reply message 1284 includes a command to launch game client 1276, player agent 1262 sends a launch request to launcher component 1272 at client device 1270. Launcher component 1272 may be a small monitor application running on client device 1270. For example, launcher component 1272 may be a terminate-and-stay-ready (TSR) program or other program that runs in the background. Responsive to a launch request being received from player agent 1262, launcher component launches game client software 1276.
The offline player may send a message to launch the client application. Then, the offline player returns from his or her offline task, such as cleaning out the garage, to start playing and interacting with the virtual world. This process saves time by allowing the offline player to overlap the launching and logging onto the game with finishing a non-game related task.
With reference now to
Player agent 1262 applies offline player rules 1264 to events observed at game server 1260. Certain offline player rules may instruct player agent 1262 to launch game client software 1276 at client device 1270 in response to particular events. If an offline player rule instructs player agent 1262 to launch game client 1276, player agent 1262 may send notification message 1282 to the offline player with instructions for launching the game client software 1276 on client device 1270. Perhaps during the user's offline time, the user is out cleaning the garage or visiting with a next-door neighbor. The user may then receive event notification message 1282 on a messaging device (not shown), such as a wireless phone or personal digital assistant, and return reply message 1284. Reply message 1284 may include a command to launch game client software 1276 on client device 1270.
If reply message 1284 includes a command to launch game client 1276, player agent 1262 sends a launch request to client device 1270. Client device 1270 receives the launch request at network interface 1278. If client device is not powered on, or in a “sleep mode,” then network interface 1278 “wakes” client device 1270 using a remote wake-up technique.
Remote wake-up is the ability for the power in a client station to be turned on by the network. Typically, remote wake-up enables an administrator to upgrade software and perform other management tasks on users' machines. It also enables remote users to gain access to machines that have been turned off. Remote wake-up is also referred to as “wake-on-LAN.”
Launcher component 1272 may be a small monitor application running on client device 1270. For example, launcher component 1272 may be a terminate-and-stay-ready (TSR) program or other program that runs in the background. In this embodiment, launcher component 1272 is configured to run when client device 1270 wakes. When launcher component 1272 initializes, it checks to see if client device 1270 powered on due to a launch request being received at network interface 1278. Responsive to a launch request being received at network interface 1278, launcher component 1272 launches game client software 1276.
Launcher dialog window 1300 also includes “Yes” button 1304, which the user may select to launch the game client, and “No” button 1306, which the user may select to decline the launch request and continue working. A person of ordinary skill in the art will recognize that other user interface elements and interactions may be used to indicate a desire to launch the game client, or a desire not to launch the game client. For example, the user may interact with dialog interface 1300 using keystrokes, voice commands, or the like.
The reply instructions tell the player how to send a message into the event notification server to launch the game client software on the user's client device. In this example, the player may select “Reply” button 1422 and reply to the message with the word “launch” to wake the game client software on the player's game client device.
In one exemplary embodiment, message composition display 1500 may include a selectable control to allow the offline player to use the offline rules to interact with the game server or to not interact. The selectable control may be a simple checkbox. This would allow the offline player to quickly respond to the game using the rules, launch the client, an then take over control when the offline player return from his or her offline task, such as cleaning out the garage.
Also, as mentioned above, the offline player may request a view of the virtual world to determine how quickly he or she needs to react or to determine what action to take (e.g., let the offline rules handle the event or drop the current offline task to respond). Thus, the offline player may weight the consequences of missing an online game event versus the consequences of shirking real world duties.
Accordingly, blocks of the flowchart illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, can be implemented by special purpose hardware-based computer systems which perform the specified functions or steps, or by combinations of special purpose hardware and computer instructions.
With particular reference to
If the player is not online—that is, the player is currently offline—then the event monitor determines whether an event is observed by or generated by the game server (block 1610). If the event monitor does not detect an event, operation returns to block 1606 to determine if the player is still offline.
If the event monitor detects an event in block 1610, the player agent determines whether the event triggers an offline player rule (block 1612). If the event does not trigger a rule, operation returns to block 1606 to determine if the player is still offline. However, if the event does trigger an offline player rule in block 1612, then the player agent launches the game client software (block 1614). Then, operation proceeds to block 1608 to disable the event monitor and operation ends.
In one embodiment, the player agent runs on the same physical machine as the game client software. In this exemplary embodiment, launching the game client may comprise sending commands to the operating system to begin execution of the game client software. In a further exemplary embodiment, launching the game client may also comprise automatically logging the player into the game client.
In another embodiment, the player agent runs on a remote machine, such as public game server 312 in
If the player is not online—that is, the player is currently offline—then the event monitor determines whether an event is observed by or generated by the game server (block 1710). If the event monitor does not detect an event, operation returns to block 1706 to determine if the player is still offline.
If the event monitor detects an event in block 1710, the player agent determines whether the event triggers an offline player rule (block 1712). If the event does not trigger a rule, operation returns to block 1706 to determine if the player is still offline. However, if the event does trigger an offline player rule in block 1712, then the player agent generates and presents a launcher dialog prompting the user for a launch decision (block 1714). The launch dialog may be the dialog user interface illustrated in
Next, the player agent determines whether to launch the game client software based on user interaction with the launcher dialog (block 1716). If the user performs an interaction that indicates a desire to not launch the game client software or if a predetermined period of time expires without any user interaction, then the player agent determines that the user does not wish to launch the game client, and operation returns to block 1706 to determine if the player is still offline.
If the player performs an interaction that indicates a desire to launch the game client software in block 1716, the player agent launches the game client software (block 1718). Then, operation proceeds to block 1708 to disable the event monitor and operation ends. In one embodiment, the player agent runs on the same physical machine as the game client software. In this exemplary embodiment, launching the game client may comprise sending commands to the operating system to begin execution of the game client software. In a further exemplary embodiment, launching the game client may also comprise automatically logging the player into the game client.
If the player is not online—that is, the player is currently offline—then the event monitor determines whether an event is observed by or generated by the game server (block 1810). If the event monitor detects an event in block 1810, the player agent determines whether the event triggers an offline player rule (block 1812). If the event does trigger an offline player rule in block 1812, then the player agent generates an event notification message (block 1814) and sends the message to the offline player (block 1816). Thereafter, operation returns to block 1806 to determine if the player is still offline.
If the event monitor does not detect an event in block 1810 or an event is detected but does not trigger an offline player rule in block 1812, the player agent determines whether a launch message is received from a messaging client associated with the offline player (block 1818). If the player agent receives a message from the offline player that includes a launch command, the player agent launches the game client (block 1820). Thereafter, operation proceeds to block 1808 to disable the event monitor and operation ends. If the player agent does not receive a message from the offline player that includes a launch command in block 1818, operation returns to block 1806 to determine if the player is still offline.
In one embodiment, the player agent runs on the same physical machine as the game client software. In this exemplary embodiment, launching the game client may comprise sending commands to the operating system to begin execution of the game client software. In a further exemplary embodiment, launching the game client may also comprise automatically logging the player into the game client.
In another embodiment, the player agent runs on a remote machine, such as game server 312 or notification server 314 in
If the launcher application receives a launch request in block 1906, the launcher application wakes the game client software (block 1908). Waking the game client may comprise sending one or more commands to the operating system to begin execution of the game client software. Thereafter, the launcher application automatically logs the player into the game server through the game client software (block 1910), and operation ends.
Thus, the illustrative embodiments solve the disadvantages of the prior art by providing a mechanism for automatically “waking” or “launching” a game client in response to particular game events occurring within a persistent world online game. A player agent for an offline player includes an event monitor that monitors for events that occur in a persistent virtual world maintained by a game server. When a game event occurs that triggers an offline player rule, the player agent may automatically activate execution of game client software. The player agent may also automatically log the player into the game server through the game client software. The player agent may generate and present a launcher dialog prompting the offline player whether to launch the game client software. Alternatively, the player agent may send a notification message to a messaging device of the offline player with instructions for launching the game client software remotely. Responsive to receipt of a message including a launch command, the player agent may automatically launch the game client software on a game client device associated with the offline player. A launcher application may run on the game client device to monitor for launch requests from a remote player agent.
It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media, such as a floppy disk, a hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and transmission-type media, such as digital and analog communications links, wired or wireless communications links using transmission forms, such as, for example, radio frequency and light wave transmissions. The computer readable media may take the form of coded formats that are decoded for actual use in a particular data processing system.
The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.