U.S. Pat. No. 7,955,175

DETAILED DESCRIPTION OF THE INVENTION

The present invention provides a complex Internet game, and specifically an RPG, for play on a social network. Users playing this game enjoy complex results based on their inputs and have the ability to build, or develop complex strategy into the way they play the game. Strategy is essential to turn based games such as RPGs, which allow the user to become engaged over a series of turns and continued play. This is desirable because it provides an enhanced user game playing experience.

The present invention also provides continued play without input from connected friends. For example, a friend in the social network may be associated with a character in the RPG of the present invention, but that character is controlled only by the user during play. This allows for continued play without input from the connected friend. While counter-intuitive for a social game, this allows for continued play when a friend is offline, with the illusion that a friend is participating in the RPG.

Internet based RPGs require an Internet system or other network.FIG. 1Ais a network configuration of an online game system according to one embodiment of the present invention.

Multiple client computers terminals103are connected to a social networking platform101over a communication channels110. Social networking platform101is any social networking system such as Facebook, Myspace or Friendster. It might also be a social network based on the iPhone or other communication network. Communication channels110may be, for example, an Internet connection. Client computer103may be any computing device capable of connecting through communication channel110and having a web browser, such as a Mac, PC or laptop. It might also be a mobile device such as an iPhone. The number of client computers103could be of unlimited number.

Multiple servers102are connected over communication channels110to social networking platform101. Server102is any server capable of processing and storing data that is generated in the course of the game. The number of server102systems could be of unlimited number. Some communications and aspects of the system involve a social network, it is possible that other aspects of the communication occur directly between the server, or servers, and client, or client, systems without involving the social network. It is possible that the social network is used only briefly in the process for user authentication, lists of friends, sharing results or other content or for only limited aspects of the game.

Mobile devices105are connected over mobile gateways111to carrier106. Carrier106is connected over communication channel110to social networking platform101. Carrier106is any mobile phone carrier including CDMA, DEN, GSM, TDMA, UMTS, WIMAX, LTE and future mobile phone based networks. Mobile devices105are any mobile devices that connect to a carrier including mobile phones, personal digital assistants (PDAs), iPhones, Blackberrys, Android systems, Palm devices, netbooks, smartbooks, broadband devices, or any other device that connects to a carrier. Some communications and aspects of the system involve a social network, it is possible that other aspects of the communication occur directly between the mobile gateways, carriers and devices, or multiple gateways, carriers and devices, and client, or client, systems without involving the social network. It is possible that the social network is used only briefly in the process for user authentication, lists of friends, sharing results or other content or for only limited aspects of the game. Mobile devices105, computer terminals103and the like are collectively referred to as user devices. Users include a single user playing the game or a friend user associated with the single user via the social network.

FIG. 1Bis another embodiment of the network configuration of an online game system of the present invention. Other embodiments known to those skilled in the art may also be used for implementation of the present invention.

In this embodiment, multiple client computers terminals103are again connected to a social networking platform101over a communication channels110. Mobile devices105are connected over mobile gateways111to carrier106. Carrier106is connected over communication channel110to social networking platform101.

Proxy server121is connected to social platform101over communication channel110. Web servers122are connected over communication channels110to load balance server121, Memcache server123, and Database server124. Database server124is connected over communication channel110to backup database server125. Load balance server121is a server similar to server102that is capable of balancing the load amongst the multiple web servers122. Web server122is a server similar to server102that is capable of processing multiple Internet programming languages. Memcache server123is a server similar to server102that is capable of storing temporary data for quick access by web server122. Database server124is a server similar to server102that is capable of processing and storing database information related to the game. Backup database server125is a server similar to database server124that is capable of acting as a backup system for database server124.

FIG. 2provides an example of server102according to the present embodiment. Server102internally includes a processing unit201, a communications unit202, a storage unit203, an operation unit204, an image output unit205, a optional sound output unit206and an interface unit207. The interface unit207transmits information to and from external devices from the internal components. The external devices connected through the interface unit207may include an optional input device208, an image display device209, an optional sound output device210, an optional external storage device211, and a communications line212. The optional input device208may not be a single unit, and can consist of any device capable of inputting such as a keyboard, mouse, or similar input device. In one embodiment, input for server102can be done remotely. Image display device209is any device capable of display such as a monitor, PDA, mobile phone or any other electronic device. A user may personalize visual settings on display device209. Optional sound output device210is any device capable of outputting sound such as speakers or a headphones jack. Optional external storage device211is any device capable of storage such as a hard drive, flash drive, storage server, or similar storage device.

The processing unit201processes information related to the game data. In the present embodiment of the invention, this information includes battle calculations, character level calculations, equipping characters, quest process, and any other information related to the game process. The processing unit201may also consist of multiple processing units working together. The communication unit202connects the server102and the communications line212through the interface unit207. This connection controls the information that is sent and received between the server102and the social networking platform101over the communication channel110.

Storage unit203may contain two types of memory components. Read only memory (ROM)213contains the system programs of the gaming system in according to the present embodiment. Random access memory (RAM)214is the re-writable storage area that stores the data generated by the processing unit201. Optional external storage device211connects to the storage unit203through the interface unit207. The storage unit203performs the processing of reading and writing the data stored in the optional external storage device211as needed by the processing unit201.

Operation unit204creates the connection between the server102and the optional input device208using the interface unit207. The operation unit performs the processing as needed for server102maintenance and analyzing data. The image display device209is connected to the image output unit205through interface unit207, and the optional sound output device210is connected to the optional sound output unit206through the interface unit207. The image output unit205processes data for server102that relates to visual data, and the optional sound output unit206processes acoustical data for server102.

FIG. 3provides an example of client computer103according to an embodiment of the present invention. Client computer103internally includes a processing unit301, a communications unit302, a storage unit303, an operation unit304, an image output unit305, a sound output unit306, and an interface unit307. The interface unit307transmits information to and from external devices from the internal components. The external devices connected through the interface unit307are an input device308, an image display device309, a sound output device310, an external storage device311, and a communications line312. The input device308may not be a single unit, and can consist of any device capable of inputting such as a keyboard, mouse, or similar input device. Image display device309is any device capable of display such as a monitor. Sound output device310is any device capable of outputting sound such as speakers or a headphones jack. External storage device311is any device capable of storage such as a hard drive, flash drive, storage server, or similar storage device.

The processing unit301in the present embodiment processes data related to web browser received data for interaction with the user. The processing unit301may also consist of multiple processing units working together. The communication unit302connects the client computer103and the communications line312through the interface unit307. This connection controls the information that is sent and received between the client computer103and the social networking platform101over the communication channel110.

Storage unit303may contain two types of memory components. Read only memory (ROM)313contains the system programs for the client, and for the present embodiment, a web browser. Random access memory (RAM)314is the re-writable storage area which stores the data generated by the processing unit301. External storage device311connects to the storage unit303through the interface unit307. The storage unit303performs the processing of reading and writing the data stored in the external storage device311as needed by the processing unit301.

Operation unit304creates the connection between the client computer103and the input device308using the interface unit307. The operation unit performs the processing as needed for client computer103maintenance and analyzing data. The image display device309is connected to the image output unit305through interface unit307, and the sound output device310is connected to the sound output unit306through the interface unit307. The image output unit305processes data for client computer103that relates to visual data, and the sound output unit306process acoustical data for client computer103.

FIG. 4is an overview process flowchart for a method of character creation for possible use in the present invention. At step400, a determination is made whether or not the user is new to the game or a returning user. If the user is new, then they will begin the primary character process at step401. Otherwise, the process will start for returning users at step407.

For new users, the primary character is the character that is associated with the application's user. This is the first character that is created and is the first character in the user's group, which may also be referred to as a Fellowship for example purposes. When a new user comes to the game application, the first thing he does is create his character, this primary character. To do so, the user is first prompted to select a character category, such as Race, at step401. Races may have attributes associated with them and may have broad classifications. For example, races may include Human, Elf, Faun, Undead, Troll, and Dwarf.

After selecting a character Race, the user may be prompted to select the Class of the character that is associated with the selected Race at step402. Classes refer to specific character types, such as a Fighter, Mage, or Thief. Each class has attributes that are combined with the Race attributes to define the character. In an alternative embodiment, a user may be prompted to select a race or class, but not both. This single selection would then provide the attributes to define the character.

Thereafter, the user is prompted to pick a character name at step403. At step404, if the user is a new user, the system moves to step405and may request (e.g., via a pop up screen) the user to authorize the installation of the application on their social network profile. Authorization of an application allows that application access to the data about the user, which is stored by the social network. The primary character creation process is complete and that character is added to the user's Fellowship at final step406. The character created may be recorded in a game log stored on the server as an achievement by the user for optional display in the user's profile on the social network. In other embodiments, the main character can be changed during the game, including class, race or name

Returning users can create additional characters that are used to build their Fellowship. The number of characters required to complete the user's Fellowship may be a preset value. At step407, a user is presented with the option to add characters to his Fellowship either by inviting friends to join his Fellowship and creating a character associated with the friend after the friend has accepted the invitation, or by purchasing additional characters to add to his Fellowship. In another embodiment, the additional characters can be “rented”. In yet another embodiment, the additional characters can be purchased, traded or sold with other users or with intermediaries. In still another embodiment, the player is forced to add the additional characters and not given the option. In even another embodiment, the player is restricted as to when the other players may be added with requirements, such as a certain level or a task being accomplished in order to “unlock” the ability to add additional characters.

If the user elects to invite a friend to join his Fellowship at step407, he sends the friend an invitation using the appropriate method prompted by the social network's internal system at step409. If the friend accepts the invitation using the social network's internal system at step410and the user's Fellowship is not yet complete as resolved in the server database at step411, then the user creates a new character for his Fellowship that is associated with the friend who accepted the invitation by starting the character creation process at step401. If the friend does not accept the invitation at step410, then the user can start the invitation process from step409once again with another friend. A user may also remove a character from his Fellowship. This may be done with or without notice to the user friend associated with that character.

If the user's Fellowship is complete as determined at step411, then the friend who accepted the invitation is eligible to be a member of the user's mercenary force or some other ancillary group, and the process is complete at step412. In other embodiments, whether a friend is a mercenary or a character can be changed later.

If the user elects to purchase a character at step407, he does so by being prompted to purchase the character using stored virtual currency on the server and selecting the appropriate option at step408. After purchasing a character to add to his Fellowship the user will create a new character that is associated with the purchased character by starting the character creation process at step401.

The process of creating the new character for returning users is the same process as for creating the primary character: the user selects a Race for the character at step401, the user selects a Class for the character at step402, and the user names the character at step403. The process continues as set forth above until the new character is added to the user's Fellowship and is stored in memory on the server and available to participate in quests. Again, at step406, the characters created may be recorded in a game log stored on the server as an achievement by the user for optional display in the user's profile on the social network. This displaying may be customized by the user to provide personalized visual game settings for the user's enjoyment and convenience.

In another embodiment, the options for characteristics of the characters can be defined by other means such as by automation, through accomplishments in quests or ambushes, by friends directly (such as by friends directly assigning the characteristics) or indirectly (such as by friends accomplishing tasks), by other users directly or indirectly, through a financial transaction such as a purchase or transaction with another player, as the result of a project, puzzles, collections or other game tasks, by giving, receiving or trading “gifts” or other objects, or through other means that would be known to a person skilled in the art. It is possible that these characteristics could be added, subtracted, removed, traded or otherwise modified, so that characteristics are not subject solely to addition or improvement. In yet another embodiment, users can sell their characters, individually, or Fellowship, in its entirety, through the system or through an external system at any point after they are created, taking with them some or all of the attributes that are specific to that character or Fellowship.

FIG. 5is an overview process flowchart for a method the present system may use for turn based game play. Turn based game play may include quests, battles, ambushes, arena combat, team formation or a combination of these. In this embodiment of the present invention, a quest assignment is made up of one or more fights/stages. A quest may comprise a set of fights against multiple targets (enemies) that the user's Fellowship must defeat in order to complete the assignment. Users will be prompted at step500to fight targets that are a part of the game (also referred to as a quest), or they may elect to fight targets that are the characters in another user's Fellowship (also referred to as an ambush). In an optional arena embodiment, both sides of a battle are controlled by users (neither side is computer controlled) with two users setting up fights and battling each other through a series of turns. In an optional team embodiment, multiple single users, each individually a user (with a fellowship based on the description herein), join together to form an army of fellowships. There is no limit to the number of fellowships that might join to form such an army. These armies might then play in quests, ambushes or arena combat as described above. In an optional combination embodiment, armies may be formed both of computer controlled and user controlled fellowships and may battle in quest, ambush or arena combat against enemies that are also made up of a combination of computer controlled and user controlled fellowships. In another optional embodiment of the game, users define the engagements, including the enemies or the structure of the engagement, or both. In yet another optional embodiment of the game, the battle outcome is affected by a player or players selecting the positions of their characters, such as having some characters positioned “in front” or “in back” during the turn.

In quest and arena embodiments, the user's characters are fighting a set of enemies. The enemies in the quest option are generated from a pre-determined list of enemies that are stored on the game server. In one embodiment of the invention, the enemies in quest mode get increasingly difficult as the game progresses. The enemies in the ambush mode are comprised of other users' Fellowship character sets and may be of comparable skill as the current user's Fellowship. In both cases, in this example, the software controls the actions of the enemies. In contrast, the user may control all the actions of the characters in the users' Fellowship. In this way, the user may play the game when friend users are offline.

If the user elects to quest, they are shown a list of available quests at step501from which the user may input a selection at step502. Thus, in this example, the user decides which quest he wants to attempt. The quests shown at step501may be based on the skill level of the characters in the user's Fellowship. In one embodiment, completed quests are excluded from the list. In another embodiment, the quests are unstructured and may be comprised of one step or more or of an undefined number of steps in which a user is allowed to continue to play as long as they want without the formal structure of a quest. In yet another embodiment, quests or their respective enemies, or both, are created by users.

If the user elects to ambush, then he is shown a list of available Fellowships to ambush at step512. The user then inputs a selection on which Fellowship to ambush at step513. The Fellowships available for ambush at step512may be based on the skill level of the characters in the user's Fellowship. In other embodiments, quests and ambushes might be combined into a single structured story or into a series of unstructured battles.

In one embodiment, the system starts the turn based play process at step503by displaying the user's characters and the enemies (also known as targets) they are fighting on the screen. Each turn until a quest or ambush is over begins at step503. At step504, the user may input the actions of each character and, depending on the action, the target of the action. The default mode if no input is entered is for the action of each character to be set to “attack” and the target to be set to the first enemy in the enemies being attacked. Actions the user can input in this example embodiment include attack, defend, use magic, and use item. It is through selecting actions for each character before each turn of play that the user influences the outcome of the battle and the ultimate outcome of the quest or ambush. This enhances the entertainment value of the game.

The user may input adjustments to his characters at step505. He may also engage an enemy that initiates the battle calculations at step506. These calculations may take into consideration-selected inputs (seeFIG. 6for additional explanation of battle calculations) that then determine the outcome of a battle (also referred to as an engagement).

In this embodiment of the invention, there are four possible outcomes of a turn. First, some of either the target's characters or the user's characters take damage, including being killed. Second, all of the target's characters in the battle are killed. Third, all of the user's characters in the battle are killed. Finally, all of the user's characters as well as all of the enemies are killed.

To decide what to do next, the system checks if all of the characters in the Fellowship are killed at step507. If they are, then the quest/ambush is completed at step510. The system then stores the results of the battle and adds information to the game log for optional display in the user's profile on the social network. If all the characters in the Fellowship are not killed, the system checks if all the target's characters are killed at step508. If they are not, the system returns to step503and starts the engagement again. Thus, the next turn in the sequence begins.

If all of the enemies are killed at step508, then the system checks if there are more stages in the quest or ambush to be fought at step509. If it's the last stage in the quest or ambush and some of the user's characters are still alive, then the quest or ambush is complete and the user has won the quest or ambush. In this example, at step510, the system stores the results of the battle and adds information to the game log for optional display in the user's profile on the social network.

If all of the target's characters are killed at step508and there are additional stages in the quest or ambush, then the enemies associated with the next stage are retrieved at step511and displayed along with the user's characters at step503. Then, a new set of turns begins again at step504. This is just one embodiment of the present invention, and in another embodiment, the system may use other factors to decide what to do on another turn of play.

FIG. 6is an overview process flowchart for battle calculations in one embodiment of the present invention. In this embodiment the process starts at step600when the user has initiated the battle on a specific turn. In another embodiment, some or all of the characteristics of a prior battle are carried forward to the next battle.

At step601, the system determines what actions each of the different enemy characters will take. These may include spell casting, attacking, or other actions available to the enemy characters. At step602, the system determines what order the user characters will be attacked. Thereafter, at step603, the system determines what actions the mercenaries will take if mercenaries are available. In this embodiment, the system will randomly select an enemy character for the mercenaries to attack.

At step604, the system determines which characters are defending the user's Fellowship. At step605, the system determines the battle turn order. The order is based on the agility skill level of each character, which might be adjusted during game play. Thereafter, at step606, the system computes the outcome of each interaction by the characters in order of the battle turn order list. This determines the effect of the battle turn on each character. For example, a character may be killed. Finally at step607, the system adjusts each character's condition accordingly, stores that information on the server, and displays the results to the user on the display or screen.

FIG. 7is an overview process flowchart for allocation of points after a character levels up in one embodiment of the present invention. When a user's character has earned enough experience points, the character's level may increase by, for example, one. In other words, the character “levels up”. The system starts at step700when the user has entered this module of the game. When this happens, the system increases the value of the character's attributes by a pre-determined number of points at step701. This number of points is based on the character's Race and Class, new level, and a random factor. A random number generating routine may determine the random factor.

In addition to the attribute value being increased automatically, the system presents the user a number of points that are set aside for the user to allocate among the character's attributes as the user chooses at step702. This is an additional method that the user may have for influencing the outcome of later battles in the game. At step703, the user is shown a table that lists the character's attributes for the character that has leveled up (e.g., maximum life, maximum mana, attack, defense, intelligence, dexterity, agility, maximum stamina, etc.) and the current values associated with each of them. At step704, the user is prompted to input which attributes he would like to increase by spending points that the user has been allocated as determined by the system. Each available attribute has a system stored different point cost which the user may spend from the allotment of points in any way he chooses at step704. The level up process is complete at step705, and the results may be immediately displayed for the user. The system stores the results and adds information to the game log for optional display in the user's profile on the social network.

FIG. 8is an overview process flowchart for the character equipping process of an embodiment of the present invention. Users can enhance their characters by upgrading their characters' attributes (e.g., attack and defense values) and by purchasing, finding, or building items that the character can use during battles to effect the outcome of the battle. In both cases, in this example, user choices affect the outcome of the game and the items that are available depend on the current level of the character and the character's Race and Class. Thus, not all items are necessarily available to all characters in a Fellowship. In another embodiment, the upgrades are created by users.

The process starts at step800when a user is prompted to elect to equip one or more characters in his Fellowship. At step801, the user is prompted to select the type of item to equip, and then at step802, the user is prompted to select which character to equip.

At step803the system will determine available item choices based on the inputs by the user from step801, step802and the availability of virtual game currency. If the system determines the type of item selected is not available for the character selected, then the system will display an appropriate message at step803. The user will then be prompted to either (i) select an item type again at step801or (ii) select a character to equip again at step802. In one example, the system determines the type of item selected is not available for the selected character because the character is not at the required level, or the character is not of the correct Race and/or Class, or the user does not have enough game currency to purchase the item. Other inputs may determine that the item is not available. If the items from step803are available for the chosen character, the system presents the user with a list of the items available to purchase at step804.

At step805, the user will select the item to equip the character with. After equipping the character at step805, the user will be prompted by the system at step806to either select a new item type to equip the selected character by returning to step801, select a new character to equip by returning to step802, or finish the character equipping process by going to step807. At step807, the system stores the results of the character equipping and adds information to the game log for optional display in the user's profile on the social network. In another embodiment, the sequence of steps the system takes will vary depending on the options the user selects. In yet another embodiment, the user can sell items or can carry more than one type of item for each character. In still another embodiment, the items can be shared amongst the characters and are not limited to use by only one specific character, but can be limited on what characters can use them.

Although embodiments of the invention have been discussed primarily with respect to specific embodiments thereof, other applications and variations are possible. For example, various configurations of input and output devices may be used in place of, or in addition to those described. Other variations can include, but are not limited to, competitive opportunities such as battles, jobs, quests, assignments, tournaments, races, fights, and competitions. Non-competitive opportunities might include but are not limited to, solving puzzles, creating objects (e.g., building a house or castle), organizing objects (e.g., building a town or kingdom), and solving problems in a simulated environment (e.g., growing a garden or running a business). Nothing in this specification should be read to limit the invention to an embodiment where the system is implemented on a single social network. The invention will function with any social network that allows game applications. The system can function outside of a social network. The system could function within multiple social networks, simultaneously or not. The invention is not limited to users with access to a device disclosed in this patent application The invention may perform, at times, before and after the social network function, entirely independently from a social network. It is possible that the social network aspects will be used after a period of use without the social network, or that the invention will be used independent of a social network after the use of the social network. It is possible that the invention will be used periodically at varying times and for varying periods of time with the social network, as it may function off-line. Functions may be performed by hardware or software, as desired. In general, any diagrams and process flowcharts presented are only intended to indicate one possible configuration, and many variations are possible. Those skilled in the art will also appreciate that methods and systems consistent with the present invention are suitable for use in a wide range of applications. While the specification has been described in detail with respect to specific embodiments of the invention, it will be appreciated that those skilled in the art, upon attaining an understanding of the foregoing, may readily conceive of alterations to, variations of, and equivalents to these embodiments. These and other modifications and variations to the present invention may be practiced by those skilled in the art, without departing from the spirit and scope of the present invention, which is more particularly set forth in the appended claims. Furthermore, those skilled in the art will appreciate that the foregoing description is by way of example only, and is not intended to limit the invention.