U.S. Pat. No. 8,187,085

DETAILED DESCRIPTION

This disclosure generally describes a MMORPG or, more specifically, a card-based MMORPG that enables characters in a virtual world to collect cards representing specified actions or powers (e.g., spells) and presents three-dimensional (3D) elements to players representing one or more aspects associated with the characters and environment. To illustrate these concepts, the disclosure illustrates an example game system100for executing, evaluating, or otherwise processing user actions in a collectible-card MMOG in a 3D environment. A collectible card game typically allows players to collect playing cards that are then used in play for respective characters. It will be understood that “player” and “character” may be used interchangeably in certain circumstances as appropriate. In some implementations, the system100may evaluate duels between wizards and/or monsters in an MMOG based, at least in part, on the cards played or selected and one or more characteristics associated with the dueling characters and/or environment. For example, playing cards can represent actions (e.g., attacks, spells) associated with combat between one or more characters or monsters. Within system100, the playing cards may represent spells that a user may select and execute in real time. Real time generally means that a user selection and action in the MMOG are temporally proximate (e.g., 500 milliseconds, 1 sec, 5 sec) such that the events appear as simultaneous or appear as substantially simultaneous. Based, at least in part, on the evaluation, the system100may present actions and character data using 3D and 2D elements. In the wizard-based examples, the system100may present 3D elements representing a spell cast and 3D elements representing the effect on character attributes (e.g., health, charms, wards, curses, traps, globals, etc). In some implementations, the system100may execute one or more of the following: identify characters, played cards and attributes of the dueling characters; three-dimensionally present information associated with characters in a 3D environment; receive information identifying actions selected by one or more users in combat such as selecting cards presenting spells; evaluate the effect of the actions based, at least in part, on a plurality of variables associated with the users (e.g., health, charms); present results or effects of the evaluation using 3D elements; filter chat between players based on, for example, chat levels associated with players (or other known information such as age of the particular user, etc.); and/or other actions. In executing a subset of these actions, the system100may manage a collectible card MMOG in a 3D environment in real time. While the following example description is centered around dueling wizards and cards representing spells, the gaming system100can cover other topics associated with characters combating or otherwise competing, such as military games, sports games, social games and/or other games.

As previously mentioned, the system100is described in the context of processing user actions in a collectible card MMOG based on fantasy characters such as wizards and monsters. For example, the system100may manage a virtual world that includes one or more of the following: receiving selections from users that design characters; identifying cards that are collected by players in connection with interacting with the virtual world; evaluating actions selected by users such as playing cards during a duel; updating character aspects based, at least in part, on the evaluated actions; presenting dialogue entered or otherwise selected by players; and/or process other aspects of the game. In connection with players selecting characters, the system100may enable players to design wizards by selecting, for example, hair styles, hair colors, facial structures, eye colors, skin colors, and clothing designs and select a wizard school. In some implementations, the system100may assign or otherwise associate cards to characters in response to at least one or more events such as completing a task or quest. In the wizard implementations, the collectible cards may represent spells such that the wizards may cast spells in, for example, a duel with other players or resources found through the course of gameplay. The spells may include damage, healing, health drain, shield, trap, card enhancements, manipulation, and/or other spells. To convey attributes of a spell to a player, the system100may present one or more symbols or icons such as a fist, to indicate the card is a damage spell and a fire symbol to indicate the card is a fire-based spell. Alternatively, or in addition, the system100may present numbers indicating, for example, a cost for casting the spell, a probability of hitting the target, and effect on the target (e.g., 400 damage).

In response to selecting cards, the system100may determine a cost for playing the cards and an effect on players. The cost for selecting a card or casting a spell may include deducting points from a power level (“mana”). For example, the system100may indicate a cost (“pip”) for casting a spell and deduct the pip from the character's power level. The effect may include, for example, damage to a player's health level, increasing a player's health, shielding against future spells cast on a target, enhancing an effect of another spell, and/or other effects associated with dueling fantasy characters. In some implementations, the system100may determine experience points associated with playing different types of cards. For example, spell types may include fire, storm, wind, myth, ice, life, death, balance, and/or other concepts. In response to experience points for a spell type exceeding a threshold, the system100may provide additional spells of that type (or another) to the character. In response to winning a duel or completing a quest, the system100may provide additional spells randomly to the player. In the process of interacting with the virtual world, the system100may present dialogue or chat entered or otherwise selected by players, non-player characters or monsters. In some implementations, the system100may filter chat based, at least in part, on the entered content and/or a chat level associated with players.

The system100may represent a character's physical and/or mental health using life points. For example, the system100may initially assign 500 life points to a character, which may have an upper limit (e.g., 2000). This upper limit can be different for each player and character. By participating in duels, the system100may deduct health points from players to represent damage. In the event a player's life points are reduced to zero, the system100may execute one or more events such as animating the character as tired, lacking energy or unconscious, presenting depressing music or sounds effects, presenting an announcement to all players, returning the player to a hub zone, and/or other events. Other players may cast healing spells to increase the life points of another player with low or zero health points. In some cases, the system100may receive a selection to flee a duel. In regards to healing, the system100may enable the players to heal over time (e.g., 10% per 30 sec), while logged out of the game, virtually paying a healer a sum of gold, and/or others.

During combat or dueling between characters, the system100may identify different stages such as planning stage, summon stage, object act stage, death stage, and ending stage. In connection with the planning stage, the system100may present competing players in a circle or combat circle that may be defined by a point, a radius, and an orientation. The orientation of the players may define initial placement of Team A and Team B. The system100may process combat areas as invisible to the players and may be used to specify an entry range such that characters (e.g., wandering monsters) can be added to duels if they are within the range. In some implementations, the system100may disable one or more user actions during combat such as movement, trading, wearing or removing equipment and/or teleporting. During the planning stage, the system100may include a universal timer that provides a period of time enabling players to select cards to play during a round. For example, the planning phase may be a 30-second time period for players to select actions at the beginning of each round. In some implementations, the system100may present a Graphical User Interface (GUI) to each player enabling them to select one or more cards representing spells to be executed, combined or discarded during the current round. The system100may prevent players from acting during a round if an action is not selected within the time period. During the summoning phase, the system100may execute the combat round based on the selected spells and parameters associated with the players. In the event that an executed spell summons an object (e.g., monster, hanging effect), the system100may present the object in the combat circle and a sequence displaying the object acting on the target of the spell. In some implementations, the system100may subtract or add health to a target based, at least in part, on a type of spell such as combat effect, damage, and healing spell. During a burn outgoing handing effects stage, the system100may implement selected charms and/or curses to modify outgoing spells. During a burn incoming hanging effect stage, the system100may implement selected wards and/or traps as effects which can modify incoming spells. During a death stage, the system100may return the player to a specified area (e.g., starting area) in response to a player's life points reaching zero. During the ending stage, the system100may add a pip to a player for each round of combat including the player. In addition, the system100may present the player with a specified amount of experience and/or items in the event that a player wins a duel. In addition, the system100may complete one or more goals or quests in the event that a player wins a duel. While these stages are for illustration purposes only, the system100may identify some, all or none of these stages without departing from the scope of this disclosure.

Turning to the example implementation illustrated inFIG. 1, the system100includes a server102and clients104a-ccommunicably coupled through a network106. In this implementation, the clients104include a GUI110for displaying information associated with an MMOG and the associated collectible card-based combat system. The server102includes memory112and processor114. The memory112locally stores a game application116that manages a collectible-card MMOG, user files118that identify information associated with a user (e.g., character, cards, status), 3D rules120that identify directives used to present 3D elements, quest module122that manages tasks and navigation in the virtual world, combat rules124that identify directives for evaluating combat between players and/or monsters, and chat rules126for identifying directives for dialogue between players. The processor114includes a presentation engine128for presenting graphical elements128aand128bthrough the GUI110, combat engine130for evaluating user actions during combat, and a chat engine132for managing dialogue between users based, at least in part, on the chat rules126. While the illustrated implementation includes the different modules in the server102, a subset of these modules may reside in the client104without departing form the scope of this disclosure. For example, the client104may include the presentation engine128and the 3D rules120.

As mentioned above, the system100includes, invokes, executes, references, or is communicably coupled with the server102. The server102can include any software, hardware, and/or firmware configured to process gaming actions using the game application116. For example, the server102may be a computing device that executes actions for thousands of users such as, for example, spells cast in a plurality of different duels. In this example, the server102may support hundreds or thousands of users simultaneously. Typically, the server102can continuously process many thousands of selected actions and/or communicate with different user devices (e.g., clients104).FIG. 1provides merely one example of computers that may be used with the disclosure. Each computer is generally intended to encompass any suitable processing device. For example, althoughFIG. 1illustrates one server102that may be used with the disclosure, system100can be implemented using computers other than servers, as well as a server pool. Indeed, server102may be any computer or processing device such as, for example, a blade server, general-purpose personal computer (PC), web server, Windows Server, Unix-based computer, handheld device or smartphone, or any other suitable device. In other words, the present disclosure contemplates computers other than general purpose computers, as well as computers without conventional operating systems. Server102may be adapted to execute any operating system including Linux, UNIX, Windows Server, or any other suitable operating system.

In the illustrated implementation, the server102can execute the game application116at any appropriate time such as, for example, in response to requests or inputs from the clients104or any appropriate computer system coupled with network106. The game application116is any suitable application software running on the server102that manages a card-collectible MMOG in a 3D environment. In some examples, the game application116may manage a persistent world, such as a virtual world, that continues to exist even after a user exits the world and/or that user-made changes to the environment state may be permanent. The game application116may support a plurality of users (e.g., thousands) submitting a plurality of actions (e.g., millions of actions per day). This example game application116may execute one or more of the following: receive and process login and logout requests, receive information identifying movement actions and chat submissions from a plurality of users; present the virtual world through the GUI110in accordance with the location information; receive selections from users that change aspects of the character and/or virtual world; update the virtual world for users in accordance with the received changes; and/or other operations.

The user profiles118can include one or more entries or data structures that include or otherwise identify one or more aspects of a user. For example, the user profile118may identify a character, information associated with the appearance of that character, collected cards and virtual items, a status, and/or other information associated with the avatar. In some implementations, the user profile118may include information identifying attributes of a character, information associated with a character's collected cards and virtual items, and values of character parameters that may change over time. In regards to character attributes, the user profile118may include or identify a type of character, a character name, login and security information and settings, gender information, attributes and character data such as health, mana, school of magical focus, virtual items owned or otherwise associated with the character, physical aspects (e.g., hair style, hair color, eye color), clothing, pets, weapons, jewelry, spells learned or collected, items collected, quests completed or currently underway, friend information, information about the virtual real estate properties they own and the ownership and placement of any furniture associated with said properties, win and loss ratings for player duels, badges earned and display preferences. In regards to collected cards, the user profile118may also include or otherwise identify playing cards in the character's possession, cards selected for the character's combat deck, spell name (e.g. firecat), spell type (e.g., fire, balance), effect type (e.g., damage, healing charms), spell accuracy (e.g., hit probability), pip cost, damage or healing amount, text and iconic description (e.g. “150 points of fire damage to target”), and/or any other aspects of the cards collected by players. As for character parameters, the user profile118may identify current values of character parameters such as health level, power level, experience level, health level, chat level, and/or other aspects of the user that may vary with time. In some implementations, the user profile118may include a duel history, a win/loss count, a quest history, school, and/or other information associated with the user.

The 3D rules120can include any parameters, variables, policies, algorithms, instructions, settings, and/or rules for presenting elements representing user information through the GUI110. For example, the 3D rules120may define a layout and/or design characteristics for displaying elements representing charms and/or wards using a hanging effect. A hanging effect may include graphical elements floating in a radius proximate a player, whether a particular player or other target, on which the hanging effect has been applied. For example, the hanging effect can be one or more 3D objects that represent spell effects triggered by other incoming or outgoing spells. In other words, the 3D objects can be dynamically created and destroyed based on combat actions. In some implementations, the 3D rules120may define layout and/or design characteristics for presenting elements, as well as transformation rules for dynamically modifying the attributes of the elements (e.g., size, color, symbol, shape) based, at least in part, on one or more events. For example, the 3D rules120may define orientation rules, placement rules, color rules, scaling rules, image transformation rules (e.g., scaling rules, cropping rules), and/or other settings for presenting 3D elements representing user information. Of course, the above parameters and rules are for example purposes, and the 3D rules120may include some, none, or different rules for presenting user elements without departing from the scope of this disclosure. For example, the 3D rules120may identify a rule indicating an expression for updating a rotational speed of an element in response to an event such as a decrease in user's health.

In some implementations, the 3D rules120may include directives for presenting both character aspects and environmental aspects during combat. For example, the combat aspects may include one or more of the following: turn order of players as shown by the relative location of the players and monsters around duel circle, current turn marker as shown by the turn marker; hanging effects applied to any participants (e.g. charms, curses, wards and traps); pips and power pips; health; name; title or selected badge, chat level information, damage/heal amount; resist/buff activation; fizzle; target marker; focus effect; global effect; and/or others. The player ring may be a ring where combatants stand during duels. Each ring may have a unique color and a corresponding iconic symbol, and the color and symbol may be used to identify casters and targets in this duel without requiring the players to refer to them by name. Charms and curses may be represented by small 3D objects that float in a circular pattern at a set radius around a player's head. Wards and traps may be represented by small 3D objects that float in a circular pattern at a set radius around a player's waist. Damage-over-time and Healing-over-time spells may be represented by small 3D objects that float in a circular pattern at a ser radius around the player's feet. Pips may be represented by small yellow dots along the front inside arc of the player ring. If the pip is a power pip, the yellow dot may be glowing brighter and/or a different color (e.g., white with a slight blue tint). Health may be represented by glowing runes along the inner colored circle of the player ring. As a player is damaged, the runes may start to black out or disappear. The player's name may be presented above their head. In response to a player getting hit with a spell, the amount and type of damage (or healing) deducted from or added to the player may be presented above their head. When player is hit with a spell (or casts a spell) and has a resistance, buff, or debuff, an iconic representation may be presented above their head. In casting spells, text identifying the spell may be shown prior to presenting a casting sequence. For spells targeting a player, text identifying the spell may be displayed prior to presenting the damage to the target. When a spell misses a target, the word “fizzle” may be presented above the intended target's head. During the planning phase, turn marker may indicate the first caster. Whenever a caster targets another combatant, a blinking indicator may light up around the target participant's ring to indicate the targeted player or monster. In some examples, the element may be a particle effect on the ground and incorporated into the dueling circle. During the execution phase, a turn marker may indicate a combatant's turn. In some examples, the element may be a particle effect on the ground or a rotating 3D element incorporated into the dueling circle. When a combatant chooses to Pass, a particle effect may be presented that goes off around him originating from the participant ring on his turn during the focus stage. Whenever a global spell is cast, a particle effect may be presented as a globe encompassing the dueling circle. In some case, the effect may be presented as the type of spell (e.g., fire, ice).

In addition, the 3D rules120may include directives for cinematic aspects based, at least in part, on different stages and/or player actions. For example, the 3D rules120may identify different camera movements and cinematic approaches for each step or stage in a duel such as a pre-determined angle and distance from a combat circle. For example, the camera may move along predetermined tracks, which, for a given stage, may include multiple random predetermined tracks for random selection. In addition, the random tracks may be different for different teams. In some implementations, the 3D rules120may identify directives for one or more of the following steps: starting, focus, casting, outgoing, global, summon, bounce, incoming, object act, hit/miss, death, and/or others. In regards to the starting step, the 3D rules120may require highlighting the circle the player is on, selecting a pre-defined camera move or angle, presenting sound effect for indicating that a player is being indicated as the current potential caster. As for passing, the 3D rules120may be substantially similar to the starting step settings. For casting, the 3D rules120may indicate that an artist-created animation and special effects particle sequence (e.g., glows, fairy dust, fire effect, lighting effects, wind or ice effects, star bursts) is played on the casting player or monster with a custom camera move or angle. Animations may be determined by the model of the character and/or the discipline of magic being cast. For outgoing, the 3D rules120may require display of an effect that may persist beyond this round of combat (e.g., a shield). These directives may include playing a custom animation sequence with a custom camera move and/or angle and creation and animation of a 3D object or creature. As for hanging effects and globals, the 3D rules120may direct that an effect be created and applied to one or more team members, or the 3D environment. In addition, the camera move and/or angle may be fixed so that it may present a certain view for various situations. As for summons, the 3D rules120may include instructions to play with a pre-defined camera move and/or angle. As for bounce, the 3D rules120may identify a pre-defined camera move and/or angle and include instructions that the rotation of the summoned object spin on the vertical access to face the new target. As for incoming, the 3D rules120may include instructions to present a cut-scene with a pre-defined camera move and/or angle. As for object act, the 3D rules120may include instructions to present a cut-scene with a pre-defined camera move and/or angle. As for hit/miss, the 3D rules120may include instructions to present a cut-scene at a custom camera angle. As for death, the 3D rules120may include instructions to present a cut-scene with custom camera angle and the defeated player or monster may persist after the cut-scene.

The quest module122can include software for assisting or otherwise aiding character movements through the virtual world. For example, the quest module122may present directions to a destination associated with performing a task in a quest. In some implementations, the quest module122may aide in the following: (1) quests the characters participate in; and (2) navigation between two points in the virtual world. For example, the quest module122may present a list of tasks associated with a quest and a character's progress. As for navigation examples, the quest module122may present user locations (e.g., point on maps) and directions to destinations selected by the user. The quest module122may display a compass indicating directions the user should take to reach a destination. In some implementations, the quest module122may include instructions for one or more of the following: presenting information associated with quests such as tasks and progress; locating characters on a map of the virtual world; determining a course between two places in the virtual world; presenting directions to a user based on a destination; and/or other aspects associated with navigating in the virtual world. In regards to locating a position on a map, the quest module122may present a map of the virtual world and indicate a character's location by, for example, overlaying a graphical element (e.g., dot, figure). The map may include structures, characters, quests, and/or other elements in the virtual world. As for navigating to a destination, the quest module122may present a 3D arrow through the GUI110indicating directions for a player. In some implementations, the 3D arrow may be presented independent of the virtual world or without presenting the arrow in the virtual world. The 3D element may rotate about a single axis. In some cases, the 3D element may not be updated based on height differences between the player and the destination. In some implementations, the direction may be based on a current goal in a quest and using a navigation map. The navigation map may identify each zone and include a graph of nodes that connect different locations in the virtual world. In some implementations, the graph may be a network that can be traversed by characters including teleporters to different zones. In these implementations, the nodes may be dispersed to make path determinations sufficiently simple but dense enough to handle crossing bridges and other fine details of the map. In some implementations, the quest module122may indicate directions to the closest goal in the event the quest includes a plurality of different goals. For example, the quest module122may determine a path to each goal with the least amount of travel time based on one or more algorithms. In some examples, a simple A* path finding algorithm may be evaluated to find the shortest path from one node or place to another. In these examples, the paths may be chained together across zone boundaries if the destination lies outside the current zone. While illustrated in the server102, the quest module122or one or more processes in the quest module122may be executed in the client104, which means any information such as the zone names of the teleporters may be located within a map data file stored in the client104. Each path generated may include a distance-traveled value for comparison to other paths. A teleport may be assigned a specific amount of travel distance (e.g., a few hundred meters). In connection with determining a path to a destination, the quest module122may include instructions for changing the orientation of, for example, a compass presented to a user as the path changes. For example, the quest module122may include instructions for presenting an arrow right when the determined path turns right. In these implementations, the quest module122may include instructions for presenting turn-by-turn directions to a user in the virtual world using one or more graphical elements. In addition to a list of goals, the quest module122may present a brief textual summary of each goal and the player's amount of progress towards completion of that goal (e.g., Defeat Ghosts (2 out of 5)). For example, the goal list may include one or more of the following: waypoint goals that may use the center of a volume they refer to; bounty goals that may look up monster(s) to kill and find their paths/spawn points and find a “center” position to point to; personal goals that may use the location players are directed to find; and/or other goals.

The combat rules124can include any parameters, variables, algorithms, instructions, rules, objects or other directives for evaluating actions between users during combat, such as magical dueling. For example, the combat rules124may determine an effect of a user (e.g., damage) based, at least in part, on the actions (e.g., spells) selected by an opponent. In some implementations, the combat rules124can implement mathematical and/or logical expressions for determining values for one or more parameters associated with a user or his character. For example, the combat rules124can facilitate determining a status value (e.g., health level) based on one or more variables associated with, for example, the environment, the initial status, actions played, and/or other aspects of combat. In some implementations, the combat rules124can include one or more of the following variables: #oP=current number of pips; PHealth=current player health; MHealth=current mob health; MMaxHealth=mob's max health; Damage=spell's damage amount; heal=spell's heal amount; and accuracy=spell's accuracy. In this implementation, the combat rules124may include mathematical and/or logical expressions based on these variables. In some examples, the combat rules124may identify an expression for determining a Damage Per Pip of a card such as, for example, the expression below:
Damage=Pips*400
In this example, this calculation may apply to offensive cards (e.g., damage, traps). In the case of an offensive spell that has no damage (e.g., Fire Trap), the Damage Per Pip may be a fixed number (e.g., 81). In some examples, the combat rules124may identify a PipMod (Pip Modifier) or a cost of a spell versus how many Pips the player currently is using, for example, the expression below:
IF (#oP/Rank=1) THEN (AggModMod=1) ELSE (AggModMod=(3.39*(1−HRatio)^2)−(6.0893*(1−HRatio))+2.75)
In some examples, the combat rules124may identify an expression for AggMod (Aggressive Modifier)/DefMod (Defensive Modifier) that may be used as a multiplier for aggressive spells. In some cases, the Defensive Modifier may be 10 minus the Aggressive Modifier such that Aggressive Modifer plus Defensive Modifier equals 10. In addition, the Aggressive Modifier may be between 1 and 9 and neither the Aggressive Modifier nor the Defensive Modifier may be less than 1. In these examples, the combat rules124may identify the following expressions:
AggMod=BaseAggMod*AggModMod
DefMod=10−AggMod
In some examples, the combat rules124may identify an expression for AggValue (Aggressive Value) that may be a modified version of DPP in light of a current number of Pips. The expression may also prevent a spell's value from climbing once the player has more pips than the spell needs. In these examples, the combat rules124may identify the following expression:
IF (#oP=PHealth) AND (#oP>=Rank)) THEN ((KFactor=1+Accuracy) ELSE (KFactor=1))
The combat rules124may restrict the lowest value of the KFactor to one. This expression may ensure that a spell will kill a target and that a mob has enough pips to cast the spell. If the expression is satisfied, the accuracy may be added. In some examples, the combat rules124may identify an expression for Overkill that determines if a spell does more damage than the target has health. The combat rules124may include the following expression for overkill:
IF ((DamagePHealth)) THEN (Overkill=1) ELSE (Overkill=1+Accuracy)
In some examples, the combat rules124may identify an expression for HEfficiency (Heal Efficiency) that determines an efficiency of a heal spell such that mobs don't violate a threshold. The combat rules124may identify the following expression for HEfficiency:
HEfficiency=(MMaxHealth−(AbsoluteValue(MMaxHealth−(Heal+MHealth)))/MMaxHealth
The AbsoluteValue portion of the expression may generate a number that represents how far away from full health the mob will be after healing. In some examples, the combat rules124may identify an expression for HFactor (Heal Factor) that may be included in a FinalDefValue calculation. The combat rules124may identify the following expression for HFactor:
HFactor=DefValue*HEfficiency*PipMod
The above expressions are for illustration purposes only and the combat rules124may include some, none, or all of the expressions without departing from the scope of this disclosure.

In addition, the combat rules124may include instructions to present text to a user in response to one or more combat events. For example, the combat rules124may include a round announcement indicating a round in a duel. The format may be “Round X” and the text may appear in the middle of the screen in large, colorful, exciting letters. The combat rules124may include instructions to indicate a pip gain. For example, when the player receives a regular Pip, the words “Pip Up!” may appear on the screen in nice, big, colorful letters. If the player receives a Power Pip, the words “Power Pip!” may appear on the screen in large, colorful, exciting letters. In some implementations, the combat rules124may include instructions to indicate end of combat. For example, the words “Victory!” or “Defeat” may appear. If the players win the combat, then the words “Victory!” may appear in large, colorful letters during the victory phase. If they lose, the words “Defeat” may appear in large, sad letters.

The chat rules126can include any parameters, variables, algorithms, instructions, rules, objects or other directives for entering and presenting dialogue between players through GUI110. For example, the chat rules126may include instructions for filtering dialogue between players based on, for example, a difference in chat levels. In some implementations, the chat rules126may include directives for one or more of the following: determining levels of players participating in a dialogue; representing the chat levels of players in the 3D environment, identifying rules for filtering dialogue based on player levels; modifying dialogue between players in accordance with the rules; displaying a user's chat level using, for example, an icon; and/or other rules. In some implementations, the chat rules126may include a list of pre-defined phrases that a user may select to present to another player. Additional phrases may be purchased, acquired through quests, and/or otherwise added to the list. In some implementations, the chat rules126may include directives associated with one or more of the following: restricting chat messages to an area of influence; sending pages to players on the same and/or different servers; providing a mechanism for players to subscribe and/or unsubscribe players; providing dialogue channels that are zone-wide only and other channels that cross all zones; and/or complying with the COPPA laws (see http://www.coppa.org/) such as logging and archiving dialogue. The chat rules126may include different permissions based on a user's status. For example, the chat rules126may include permissions such as an easy chat, a secure chat, an open chat, and/or others.

The chat rules126may identify directives for easy chat that present a plurality of selectable actions and/or phrases for a user. For example, the instructions may include a list that may be opened by clicking on an icon in the upper right hand corner of the GUI110. In some implementations, the chat rules126be may instructions for presenting selected chat to players within a specified range (e.g., 30 meters). The range at which these bubbles are presented may be adjustable. In some cases, the chat rules126include instructions for switching between a chat bubble and/or a window in the GUI110. The distance between when the chat bubble appears on top of a user's head, and the distance to when the dialogue appears on the side of the screen may vary between users. For example, the range at which chat bubbles appear above the head may start at 30 meters. If the speaker is out of view, the chat rules126may include instructions for presenting the dialogue on the side of the GUI110that is closest to the speaker, but kept within the boundaries of the player's screen such that the text is fully readable, and may be prefaced by the speaker's name. In some implementations, the chat rules126may prevent or remove presentation of a dialogue box when an off-screen speaker is outside a specified range (e.g., 20 meters). In addition, the chat rules126may identify a plurality of different chat boxes and directives for presenting dialogue in the different boxes based on one or more parameters. For example, the chat rules126may identify 10 predetermined slots that are each fixed in size. The parameters for presenting the dialogue in different boxes may include, for example, proximity, friend, chat level, player age, and/or others. In addition, the chat rules126may include instructions for presenting dialogue such as font, text, color, bubble tint, orientation and/or other aspects for presenting dialogue in a 3D environment. For example, the chat rules126may include instructions for presenting dialogue in a white comic book style bubble with black text and rotating the dialogue to face each player. In some implementations, the chat rules126include instructions for scaling dialogue based, at least in part, on a distance between players. For example, the size of the chat bubble may scale down linearly to 20% at 30 meters and then disappear at greater distances. In some implementations, the chat rules126may specify a period of time for presenting dialogue. For example, chat bubbles and/or the accompanying off-screen chat boxes may stay on the screen for 4 seconds. In some implementations, the chat rules126may include instructions for deleting or at least modifying other graphical elements associated with the player presenting dialogue. For example, the presented dialogue may replace a name billboard when a player presents dialogue.

In addition, the chat rules126may include instructions based on different types of dialogue. For example, the chat rules126may identify a plurality of different selectable dialogue types and rules for presenting dialogue based on the selected type. The chat rules126may identify “Text” as a dialogue type and present the entered dialogue to a single player. In addition, the chat rules126may include instructions for presenting elements different from text such as, for example, socials and/or emotes. For example, emotes may include animations applied to a player's character and may include sound effects. In some implementations, the chat rules126may include instructions to automatically present an emote if a text option is selected. For example, an emote may be a social animation and/or an associated text phrase describing the action being performed, such as “Susan waves to you.” or “Timmy takes a bow.” Some emotes may not be associated with text. In some implementations, the chat rules126may include instructions to add actions to, for example, a character. For instance, the chat rules126may include instructions for adding facial expressions (e.g., increasing eye size, turning mouth to a smile) in response to, for example, a selected phrase. The chat rules126may include instructions for one or more of the following: eye animation; mouth animation; character animation; character animation; sound effect; and/or others.

In regards to open chat, the chat rules126may filter dialogue exchanged through open chat using, for example, dictionaries of acceptable words and unacceptable phrases. In some examples, the chat rules126may include a white list that identifies acceptable words for use in filtered chat. In these cases, the chat rules126may include instructions for presenting words colored RED as they are being typed into the interface unless that word is identified in the white list. For example, the letters in the word belligerent may change colors during typing as described below: (1) bel . . . (at this point, the letters are red); (2) bell . . . (at this point, the letters are white because the word “bell” is valid); (3) belli . . . (at this point, the letters turn red); and (4) belligerent . . . (at this point, the letters turn while white). In some cases, the words in red may be replaced by a character string such as “#$%!.” when this dialogue is displayed to other players of filtered chat or lower chat level. In some case, the chat rules126may include a Black List that identifies phrases that are prohibited and include instructions for presenting the letters in, for example, red. For example, the letters in the phrase “look under my robe” may change color during typing as follows: (1) Look (would be white); (2) Look under (would be white); (3) Look under my (would be white); and Look under my robe (at least the phrase “under my robe” would be red). The chat rules126may include instructions to compare entered text to one or more lists in response to a last user action (e.g., spacebar hit). In some implementations, the chat rules126may include directives associated with one or more of the following: predicting text to help with spelling issues; securing chat level based on a parent password; and/or other features. The chat rules126may include instructions to open a text entry box in response to a user action (e.g., pressing enter). The chat rules126may include instructions for presenting text based on the number of characters entered. For example, if the character number exceeds a character limit (e.g., 54), the chat rules126may include instructions to remove the text from the chat box and automatically display the text in a normal billboard style chat bubble. In addition, the chat rules126may include instructions for presenting text to nearby players, only to a single player (e.g., selected from the GUI110or from the Friends); and/or others. In some implementations, the chat rules126may include instructions for using different background colors and shapes for chat bubbles based on the type of communication. For example, the chat rules126may include instructions for chat bubbles as follows: Open Chat—different color background than Easy Chat; Easy Chat—different color background than Open Chat; Open Tell—Same color as Open Chat, different shaped chat bubble; and Easy Tell—Same color as Easy Chat, different shaped chat bubble. In some implementations, the chat rules126may prevent texts entered from a player using open chat from being presented to a player using easy chat. Though, the chat rules126may include instructions for indicating an attempt to communicate such as a sound effect and/or a nonsensical character string in the dialogue box. The chat rules126may include instructions for limiting access to open chat based on age, parental consent, and/or other factors.

Processor114executes instructions and manipulates data to perform operations of the server102. AlthoughFIG. 1illustrates a single processor114in the server102, multiple processors114may be used according to particular needs, and reference to processor114is meant to include multiple processors114where applicable. In the illustrated implementation, the processor114executes various software such as the illustrated presentation engine128, combat engine130and chat engine132at any appropriate time such as, for example, in response to a request or input from a user of the client104or any appropriate computer system coupled with network106. Indeed, the software may be written or described in any appropriate computer language including C, C++, Java, Visual Basic, assembler, Perl, any suitable version of graphics software or APIs, as well as others. It will be understood that the software may include any number of sub-modules, such as the illustrated engines and third party modules or libraries, or it may instead be a single multi-tasked module that implements the various features and functionality through various objects, methods, or other processes. Regardless of the particular implementation, “software” or “computer readable instructions” may include any software, firmware, wired or programmed hardware, or any combination thereof (embodied on or in tangible computer readable media) as appropriate to, when executed, instruct the respective one or more processors.

The presentation engine128can include any software operable to present data associated with a character. For example, the presentation engine128may present 3D objects (e.g., floating 3D objects) that indicate one or more aspects of the character (e.g., charms, curses, wards and traps) and dynamically update the presentation based, at least in part, on one or more aspects of, for example, a duel. In some implementations, the presentation engine128may execute one or more of the following: identify one or more attributes of a wizard in a user profile118; generate a player avatar or character based, at least in part, on the identified attributes; receive a request from the user to view one or more graphical elements (e.g., items) from a user; identify one or more aspects of the requested element in the user profile118; generate a presentation of the graphical element to display through the GUI110; identify one or more characters in a duel and associated actions selected from the users; dynamically present and/or update presentation of graphical elements in response to user actions; identify 3D rules120associated with a player's context; present graphical elements to the user in accordance with the 3D rules; and/or other presentation process with players interacting in a virtual world.

The combat engine130can include any software operable to evaluate actions executed by players in a duel. For example, the combat engine130may determine how much damage resulted from a spell based, at least in part, on parameters such as the played card, the environment, and/or other parameters. In some implementations, the combat engine130may execute one or more of the following: identify a player selection and associated character attributes based, at least in part, on the corresponding user profiles118; group multiple players in teams in accordance with one or more user selections; identify combat rules124based, at least in part, on a format associated with the duel (e.g., player versus player, team versus team); identify the turns for each player in a duel; notify a player when their turn is identified; advance the turn to the next player when the previous player either selects an action or times out; identify cards selected by the users in the duels and associated aspects of the spell associated with that card (e.g., type, damage, cost); the target of any selected card, if any; identify one or more equations associated with the played card using the combat rules124; determine results of played cards based, at least in part, on the identified equations and variables associated with the combat; and/or update user profiles118in accordance with the determined results. In some implementations, duels may be various combinations of players such as, for example, player versus player, players versus monsters, player and friendly monsters versus players and friendly monsters, and player and friendly monsters versus monsters. For example, the duels may include 2 to 8 players and/or monsters and/or friendly monsters. Based on the format of the duel, the combat engine130may identify one or more combat rules124associated with the format. In some cases, the duel may be between players and characters generated by the game application116such as monsters. During combat, the combat engine130may receive a selection from a user that identifies a card from a plurality of selectable cards in a user's deck and identify one or more expressions from the combat rules124associated with the played card. As described above, the combat engine130may select an expression for determining an amount of damage to a player resulting from a played card. In connection with solving identified expressions, the combat engine130may determine values for one or more parameters included in the identified expression. The combat engine130may determine values from user profiles118, values from the virtual environment, and/or other aspects of the virtual world. In addition, the combat engine130may initiate an update of the virtual world such as presenting visual and/or sound effects, updating graphical elements associated with players, and/or other effects experienced by the user.

The chat engine132can include any software operable to manage dialogue between players. For example, the chat engine132may filter dialogue between players based, at least in part, on players' chat levels and/or dialogue content. In some implementations, the chat engine132may execute one or more of the following: receive requests to present dialogue to one or more users from the clients104; identify one or more rules associated with the players using the chat rules126; determine one or more parameters associated with the users (e.g., distance, chat level) using, for example, the user profiles118; determine whether the text matches one or more lists (e.g., white list, black list) included in the chat rules126; present the text to the users in accordance with the rules and the one or more parameters; dynamically update the text based, at least in part, on additional text entered by the users; and/or other processes. In some implementations, the chat engine132may receive a request identifying dialogue (e.g., selected, user entered) and a dialogue type such as player to player (e.g., whisper, secured chat). In connection with the request, the chat engine132may identify a chat level associated with the requesting player based, at least in part, on the user profile118. For example, the chat engine132may determine a player has an open chat level or an easy chat level. In regards to filtered chat, the chat engine132may compare entered text to one or more lists of prohibited and/or acceptable text. In response to at least a match, the chat engine132may dynamically update the text in accordance with the rules such as replacing text with a string of characters or updating the color of the letters. In some implementations, the chat engine132may present the dialogue based on parameters associated with the environment. For example, the chat engine132may switch between presenting the dialogue in a bubble or chat box based on proximity of characters and/or display preferences of the player. In the case that the game application116presents multiple dialogue boxes, the chat engine132may switch the text between a plurality of different boxes based on, for example, length of text, time entered, and/or other parameters.

Clients104a-care any devices (e.g., computing devices) operable to connect or communicate with the server102or network106using any communication link. Each client104includes, executes, or otherwise presents a Graphical User Interface (GUI)110and comprises an electronic device operable to receive, transmit, process and store any appropriate data associated with system100. While the illustrated implementation includes example clients104a-c, system100may include any number of clients104communicably coupled to the server102. Further, “client104,” “user,” “player,” and “character” may be used interchangeably, as appropriate. Moreover, for ease of illustration, each client104is described in terms of being used by one user. But many users may use one device or one user may use multiple devices.

As used in this disclosure, a user of client104is any person, group, organization, a process implemented in software or hardware, or any other entity that may use or request others to use system100. Client104is intended to encompass a personal computer, touch screen terminal, workstation, network computer, kiosk, wireless data port, smart phone, personal data assistant (PDA), one or more processors within these or other devices, or any other suitable processing or electronic device used by a user viewing content from the server102. For example, the client104may be a PDA operable to wirelessly connect with an external or unsecured network. In another example, the client104may comprise a laptop that includes an input device, such as a keypad, touch screen, mouse, or other device that can accept information, and an output device that conveys information associated with questions and answers posted using the server102, including digital data, visual information, or GUI110. Both the input device and output device may include fixed or removable storage media such as a magnetic computer disk, CD-ROM, or other suitable media to both receive input from and provide output to users of clients104through the display, namely the client portion of GUI110.

The GUI110comprises a graphical user interface operable to allow the user of the client104to interface with at least a portion of system100for any suitable purpose, such as viewing a virtual world in real time. Generally, the GUI110provides the particular user with an efficient and user-friendly presentation of data provided by or communicated within system100. The GUI110may comprise a plurality of customizable frames or views having interactive fields, pull-down lists, and buttons operated by the user. The GUI110can be configurable, supporting a combination of graphical elements, to present the Web pages118including the graphical elements128. The term graphical user interface may be used in the singular or in the plural to describe one or more graphical user interfaces and each of the displays of a particular graphical user interface. The GUI110may be any graphical user interface, such as a generic web browser or touch screen, that processes information in the system100and efficiently presents the results to the user. The server102can accept data from the client104via a client application or web browser (e.g., Microsoft Internet Explorer or Netscape Navigator) and return the appropriate HTML, XML, and/or other responses to the browser using the network106, such as the graphical elements128.

The graphical elements128may include any graphical elements that present 3D elements to the user of the client104. For example, the graphical elements128may represent spells in connection with a user selecting a card to play. In some implementations, the graphical elements128may be interactive elements such that a selection executes one or more processes (e.g., casting a spell). The graphical elements128may include one or more of the following: text, color, sound, buttons, fields, and/or any other suitable electronic element. For example, the graphical elements128may be a question mark floating over a character's head that presents information to a player in response to a selection.

As previously mentioned, the client104may execute one or more processes illustrated as executed by server102. In some implementations, the client104may include a client-side module134that processes information associated with the game application116. For example, the server102may transmit messages136to the client104, and the client104may transmit messages138to the server102. The server102may transmit a message136to the client-side module134bindicating a duel has begun. In addition, the server102may transmit information indicating a player's hand at the beginning of the planning phase. In response to at least a user selecting one or more graphical elements128, the client module134bmay transmit information identifying one or more cards selected by the user for the current round. The server102may transmit a message134bindicating actions selected by combatants in the duel. Using the included information, the client-side module134bmay resolve the combat based, at least in part, on the selected actions and present a 3D sequence illustrating the results. In some implementations, the client-side module134bmay execute one or more processes associated with the combat engine130, such as determining the results of a duel, and one or more process of the presentation engine128for presenting 3D elements128illustrating the effect of the duel. The server102may transmit messages to the client-side module134indicating one or more of the following: duel ended; a new phase of combat (Planning, Execution, Resolution, and Ended); new player has joined duel; player left duel; a teammates selected action; enchant an identified card; pips of players at the start of the duel; and/or other information.

Network106facilitates wireless or wireline communication between the server102and any other local or remote computer, such as clients104. Network106may be all or a portion of an enterprise or secured network. While illustrated as single network, the network106may be a continuous network logically divided into various sub-nets or virtual networks, so long as at least portion of the network106may facilitate communications of answers and references between the server102and at least one client104. In some implementations, the network106encompasses any internal or external network, networks, sub-network, or combination thereof operable to facilitate communications between various computing components in the system100. The network106may communicate, for example, Internet Protocol (IP) packets, Frame Relay frames, Asynchronous Transfer Mode (ATM) cells, voice, video, data, and other suitable information between network addresses. The network106may include one or more local area networks (LANs), radio access networks (RANs), metropolitan area networks (MANs), wide area networks (WANs), all or a portion of the global computer network known as the Internet, and/or any other communication system or systems at one or more locations.

FIGS. 2A-2Fis a flowchart illustrating an example method200for executing a duel between users in accordance with some implementations of the present disclosure. At a high level, the method includes the following twelve stages: (1) planning phase; (2) starting stage; (3) focus stage; (4) target stage; (5) outgoing stage; (6) casting stage; (7) global stage; (8) summon stage; (9) bounce stage; (10) incoming stage; (11) object act stage; and (12) release stage. Examples of the method200may be described in terms of the computer system100. But it should be understood that any other suitably configured computer system or environment may also be used to perform, request, execute, or otherwise implement the method200. In other words, method200may use any appropriate combination and arrangement of logical elements implementing some or all of the described functionality.

Turning to the illustrated process, method200begins at the planning stage indicated by step202. For example, the game application116may present the teams of players in, for example, an arena and users of the client104may select cards through the GUI110to include in their dueling deck. In addition, the users may select specific cards for the identified round. For example, a user may select a shield spell through GUI110. Next, at the starting stage, a marker is presented to the duelers indicating the player to act at step204. In the example, the game application116may present a graphical element128that highlights or otherwise indicates a player's turn. If the player selects to pass this turn at decisional step206, then execution moves to step208where the player's action is omitted at this round. In the example, the game application116may determine that the acting player may have omitted actions this round enabling, for example, the player to determine a strategy for next round. If another caster in the same team is available at decisional step210, then execution returns to step204. If another caster is not available in the team, then execution returns to step202. Returning to decisional step206, execution proceeds to decisional step212if the player is not focusing. If the selected target is not alive at decisional step212, then execution proceeds to step208where a player's new target is identified. If the selected target is still alive, at step214, a target designator is applied to the target such as a target marker.

If a player initiated a caster outgoing spell effect at decisional step216, then at step218, a hanging effect is applied to the target. Returning to the example, the game application116may present a 3D element overlaying the target and indicating an attack such as a flame. If the spell is absorbed by the target at decisional step220, then execution proceeds to decisional step222. If another caster is included in the team, then execution returns to step204. As for the example, the game application116may select a next player in the team in connection with determining a target. If another caster is not available in the team, then execution returns to step202. Returning to decisional step216, if the player does not select an outgoing spell effect, then execution proceeds to decisional step224. If the player selects a spell to target an incoming spell effect, then at step226, a hanging effect is applied to the player. As for the example, the game application116may overlay a 3D element on the player to indicate the incoming spell. If the spell is absorbed at decisional step228, then execution proceeds to decisional step222. If the spell is not absorbed, then execution returns to decisional step224.

If the spell selected does not target the incoming spell effect, then execution proceeds to decisional step230. If a target is hit by the selected spell, then at step223, then a hit animation sequence presented to the user. For example, the game application116may present an animated sequence to the users indicating the spell affected the target. If a global active is identified at decisional step234, then at step236, a current global effect is applied. Again in the example, the combat engine130may identify a global effect using the combat rules124and applied the global event to the duel circle presented through the GUI110. If a global active is not identified, then at step238, then a summon object is presented to the users. If the spell is a global at decisional step240, then at step242, the current global effect is replaced. Execution then returns to204. Returning to decisional step240, if the spell selected is not a global, then execution proceeds to decisional step244.

If the spell is a caster damage type effect, then at step246, a hanging effect is applied to the caster. Execution then returns to decisional step244. If the spell is not a caster damage type effect at decisional step244, then execution proceeds to decisional step248. If the spell is a target damage type effect, then at step250, then the spell attempts to trigger a hanging effect, if an appropriate defensive hanging effect is already on the target. The damage also results in an object act being presented. If a new target is selected at decisional step252, then at step254, a target designator is identified. If a new target is not selected, then execution returns to decisional step248. If the spell is not a target damage type effect, then at step256, an object act is presented. For example, the combat engine130may present an animation of a figure representing a spell. At steps258and260, a hit sequence and any resistance information are presented to the users. For example, the combat engine130may animate a target illustrating an effect and any resistance the target initiates. Next, at step262, health is adjusted or another effect on the player is applied. Again in the example, the combat engine130may determine values for one or more parameters associated with the target based, at least in part, on expressions in the combat rules124and user variables in the user files118. If another action is selected at decisional step264, then execution proceeds to step254where a target designator is identified. If another action is not selected, then execution proceeds to decisional step266. If the release stage is identified at step266, then the summoned object is released at step268. If the release stage is not identified, then execution proceeds to decisional step270. If the target dies, then the target death is presented to the users at step272. If the target does not die, then execution proceeds to decisional step274. If more targets are identified, then execution proceeds to step254where a new target designator is identified. If no additional targets are identified, then execution proceeds to decisional step276. Returning to decisional step230, if the target is missed, then a casting sequence miss is presented to the users at step278. Execution then proceeds to decisional step276. If another caster is available, then execution proceeds to step254where a target designator is identified. If another caster is not available, then execution proceeds to decisional step280. If the duel has ended, then an ending sequence is presented to the users at step282. If the duel has not ended, then execution returns to step202.

FIGS. 3A-Gis a schematic chart300illustrating different channels associated with a duel. In this example, the chart300includes a music channel302, a caster channel304, a target channel306, an object channel308, a general channel310and a camera channel312. The channels302-312illustrate different categories and processes that may occur in each category and relative timing between the different channels. For example, the music channel302indicates that music may be presented to the users at different stages in the duel such as the planning stage, the combat stage, the death and the victory/defeat stage. The caster channel304generally illustrates processes associated with the caster including animation sequences. The target channel306generally illustrates processes associated with the target including animation sequences. The object channel308illustrates the relative timing that an object is presented during the combat sequence. The general channel310illustrates the presentation of graphical elements associated with the duel and timing relative to the other channels. The camera channel312illustrates the timing of various camera moves and/or angles during the course of the dual relative to the other channels.

FIGS. 4A-Fillustrates a pictorial chart400of the various stages in a duel. In this example, the chart400includes images402-428that illustrate various camera angles, graphical elements, actions, and/or other aspects that may be presented at various stages. The planning-phase image402illustrates two teams facing each other and surrounding an arena. The starting-phase image404, the focus-stage image406, and the target-stage image408include a graphical element underneath the first player to act. The casting-stage image410illustrates that the caster performs one or more actions in response to at least a user selecting a spell. The outgoing-stage image412illustrates an example of a hanging effect, in this case a 3D floating shield, in front of the caster. In the event the selected spell summons an object, the summon-stage image414and the bounce-stage image416illustrate that a 3D object is presented on the arena and faces the target. The incoming-stage image418illustrates a 3D floating shield in front of the target. The object-act-stage images420and422present an animation of the object acting on the target and the target's response to the hit. The release-stage image424illustrates that the summons object is released from the stage. The death-stage image426illustrates that a death animation is presented in response to at least the target dying. The ending-phase image428illustrates that the winning team is presented standing, while the losing team is lying on the ground.

FIGS. 5A-Dillustrate displays associated with combat.FIG. 5Aillustrates an example interface500for a planning phase in accordance with some implementations of the present disclosure. The planning-phase interface500includes interactive graphical elements that enable a player to organize a strategy and execute plays such as selecting cards. For example, the interface500may include interactive elements that execute one or more of the following: cast a spell on a player; cast a global spell; cast a spell on another spell (“Enchantment”); discard a spell; pass; flee; chat; and/or others. In this example, the interface500includes a countdown timer502, character-information tabs, focus button506, discard button508, global icon510, flee button512, hand514, a deck counter516, and chat windows518aand518b. The interface500is for example purposes only and a planning-phase interface may include some, all, or none of the illustrated interactive elements.

Countdown timer502may indicate the time available to the player to select an action. In some implementations, if all players make their selection before the end of the time period, the duel may immediately proceed to the execution phase before the timer counts down. The countdown timer502may be configurable by, for example, the game designer. In the event the timer runs down prior to one or more players making a selection, those players may not participate in that duel round. During the planning phase, a player may alter, update or otherwise modify selected actions if additional time is left on the timer502. In some cases, a window may pop up indicating that other players are still making selections. In this case, a button may be presented including the selections “Go Back” or “Change.” Selecting this button may return the player back to the planning phase interface500to enable a player to modify the selected actions. The timer502may not reset, and if a selection is not made in time, the player may default to ‘pass’ or Focus. The character information tabs may present information associated with a combatant in response to a user selection. The name tag may present the player's name or the team or monster name. The health min/max tab may present the current health level and the maximum health level of a player. The pips tab may present the power used to cast spells. In some implementations, each pip (e.g., yellow) or power pip (e.g., white with a tint of blue) may be displayed as separate graphical elements or numerically. The selected spell tab may presents icons representing a selected spell and a color of the player ring may be presented around the icon. In some implementations, a camera facing object that appears apart of the selected spell tab may be displayed above each player's head during the planning phase such as, for example, once each character has selected an action for the round. For example, the icon of that spell and a color of the target's ring around the icon may be presented.

The pass button506may be a graphical button that enables a player to skip this round and may result in the player gaining a pip or increase in power level. In some implementations, selecting the pass button506may end a player's turn and may prevent the player from changing the action. In some cases, the pass button506may be replaced with a change button that enables the player to change their selection. The discard button508may be a graphical button that enables a player to discard a selected spell. The discarded spell may be temporarily removed from this player's deck and may not be drawn again for the remainder of this combat. If the discarded spell is a treasure card, the discarded card may be temporarily removed from this player's deck of available cards and may not be drawn again for the remainder of this combat. In addition to the discard button508, a player may discard a spell by, for example, right-clicking on the spell. The global icon510may be presented in the upper right hand corner of the planning phase interface500. The icon510may indicate when a global spell is played and active. In some examples, the icon510may be presented only during the planning phase. To cast a global spell, a player may click or select the appropriate card. In some implementations, the 2D interface elements associated with invalid targets may be presented as gray, and the 3D representation of valid targets may be surrounded by a glow or light effect.

The flee button512may present a graphical button that may remove a player from combat and may send the player back to the hub zone of the world. In some implementations, a confirmation window may pop up such that clicking “Yes” may execute the actions. The hand514may present a variable number of cards such as, for example, 1 to 7. The presented cards may be drawn from a collective deck such as the cards in a player's Deck and any cards granted by equipment the player may be using or wearing. In some implementations, the hand514may present randomly selected spells drawn from the player's decks and may represent the player's hand and available to spells during the round. To cast a spell on another player, a player may click or select on the spell in the hand514and select the character information tab504of the target. In some implementations, invalid targets may be presented as grayed. If a valid target is selected, the spell may be displayed on a character box and a color around the spell matching the color of your target's box may be presented. To cast a spell on another spell, a player may click or select a spell and then click or select on a target spell card. In some implementations, invalid targets may be presented as gray. If a valid target is selected, the enchant card may disappear and the target spell may be marked visually as enchanted. The enchanted spell, after being played, may not be retrievable. In some examples, enchanted spells may not cost any pips to cast. In other words, the enchantment spells or other spells may have a rank of zero.

The deck counter516may indicate how many cards a player has left in their deck. The presented number may not include the cards presented in the hand514. In some implementations, discarded cards may not be shuffled back into the deck until the next duel. The deck counter516may be formatted as “Deck X of Y” where X is the number of cards remaining and Y is the total configured cards plus treasure cards. For example, if the player had 30 cards configured in the deck, plus 15 treasure cards, the counter516may display “38 of 45” after the initial hand514is dealt. The chat windows518aand518bmay present dialogue between players. For example, the entered text may appear in a bubble above their heads. The chat windows518aand518bmay be an easy chat button and a secure chat button.FIG. 5Billustrates a graphical element520associated with health of a player. The player's health may be represented by glowing runes along the inner colored circle of the element520and the player may be presented as standing on the element520. As the player takes damage during duels, the runes on the element520may be replaced with black dots, disappear or otherwise blacked out.

FIGS. 5C-Dillustrate example format522and an example image524of a victory screen after a player has won a duel. The example format522includes a presentation of an award box526and a player528. The award box526may include text and/or an image of an item award to a winning player. In this example, the award box includes the text “Items Awarded” and the name of the item “Necromancer Boots of Valor” with an image. In another example, the award box526may be replaced with a reward icon and floating text detailing the reward granted. In some implementations, if any players are left alive after combat, then these players may be presented with a victory screen in accordance with the format522. In some cases, the camera may be focused on all players and a window appears in the upper portion of the screen. The players may be animated to perform one or more actions such as a victory dance. The award items may include gains, loot, gold, and/or other items. If player wasn't awarded loot, the player may not be presented such as format526. Gold gained may be displayed in one lump sum to the players. In regards to equipment and gold, a 2D picture of the item(s) received may be presented such as those illustrated in image528. If multiple items are received, these items may be presented one at a time, all at once, or other combinations. Gold may be represented as a gold coin followed by a number of pieces of gold received. When the victory phase ended, the player may regain control of his character.

FIGS. 6A-Iillustrate example icons602-616and an example spell card618that includes icons to indicate aspects of the spell. The icons602-616and the spell card618are for illustration purposes only and a gaming system may include some, all or none of the represented attributes or card format. Referring toFIG. 6A, the icon602illustrates a fist and may be included on a damage card. Damage cards may inflict a certain amount and kind of damage depending on the card's school and opponent. Referring toFIG. 6B, the icon604illustrates a heart and may be included on healing cards. Healing cards may give players an ability to heal themselves and/or other players and/or friendly monsters. Referring toFIG. 6C, the icon606illustrates a broken heart and may be included on health drain cards. Health drain cards may inflict a certain amount of damage and some portion of the amount may be added to the caster's health points. Referring toFIG. 6D, the icon608illustrates a shield and, when used during combat, may reduce the damage of either outgoing or incoming spells of one or more damage types by a certain percentage, which may depend on the spell. In some implementations, these cards may cost 0 pips. Referring toFIG. 6E, the icon610illustrates a four-leaf clover and may be included in charm or curse cards. Charm and curse spells may increase or decrease the overall damage, healing, or accuracy of outgoing spells by a certain percentage or fixed amount. Shield and trap spells may increase or decrease the overall damage or healing of incoming spells by a certain percentage or fixed amount. In some implementations, these cards may cost 0 pips. Referring toFIG. 6F, the icon612illustrates a spiral and may be included in global spell cards. Global spell cards may act similarly to charms or curses except they may cost more pips, may last for the duration of the battle, and/or may affect all participants in the duel. Referring toFIG. 6G, the icon614illustrates an open hand and may be include on manipulation cards. Manipulation cards may serve a variety of purposes. For example, manipulation cards may summon friendly monsters, may make your opponent reshuffle his/her deck, or may give pips to other players. Referring toFIG. 6H, the icon616illustrates a star and may be included in enchantment cards. Enchantment cards may attach to regular cards to improve or modify their effect, or turn one spell card into a different spell card. In some cases, once an enchantment card is attached to a regular card, a new treasure card may be created. Referring toFIG. 6I, the card618is an example playing card that represents a spell and aspects of the spell are indicated on the face of the card. The example card618includes a pip field620, a school icon622, type icon624, an odds field626, and effect field628. The pip field620indicates that the spell costs 3 pips to play. The school icon622indicates that the spell is from the fire school. The type icon624indicates that the spell is a damage spell. The odds field626indicates that the probability of hitting the target is 60%. The effect field628indicates “400 (Fire Symbol) (Damage Symbol)” and may mean that this spell will do 400 Fire Damage.

FIGS. 7A-Gillustrate example displays702-712associated with one or more aspects of exchanging dialogue between players. Referring toFIG. 7A, the display702illustrates an example of menu chat. In this example, players select a word or phrase from the menu716, and in response to the selection, a bubble may present the selected text above the player's head. In some implementations, the menu716may include a list of categories such as activities or happy, and if the category is selected, then a plurality of different selectable phrases and/or emote animations may be presented to the player. Referring toFIG. 7B, the display704illustrates an example of open chat. In this example, players type in words in the text box718, and in response to a selection (e.g., pressing enter), the words are presented in the dialogue field720. In some implementations, open chat may include the following restrictions set as default: under 13 players are restricted to Easy Chat only; 13-18 year olds have filtered chat based on the white and black lists discussed with respect toFIG. 1; 18+ year olds get open chat with only a profanity filter; and/or others. The profanity filter may be built of two lists, substring and exception. In some implementations, any word containing the substring is filtered and any word containing the substring that appears in the exception list is allowed. For example, the string “Ass” is a substring match but “!grass” and “!assassin” are allowed exceptions.

FIG. 7Cis a display706illustrating an example format associated with secure chat between friends. The display706includes a generate button722, a code window724, and a validation button726. In response to a player selecting the generate button722, the display708inFIG. 7Dmay be presented to the user indicating a suggested friend code728and “OK” button730to accept the friend code. In some implementations, the real life friend code728may only work once since after the first use the code will no longer work. In addition, the code may have a limited lifespan (e.g., 2 days). The code window724receives a friend code enter by the user, and the validation button726, when selected, initiates a validation process for the enter code. In the event the validation process fails, an error message may be presented such as “That is not a valid code, please try again!” In the event of validation, a success message may be presented such as a success message. “You are now Real-Life Friends with [Friend's Name]!” In general, secure chat may provide a free chatting environment, but the players should typically know each other in the outside world to be able to activate secure chat. In some implementations, secure chart does note filter dialogue based on the white list. The dialogue may be filtered through a profanity filter instead of the black list. After a friend has been validated, a user may select one of a plurality of different selectable actions from the menu732in the display710ofFIG. 7E. For example, the player may select secure chat with the friend from the menu732.

FIG. 7Fis display712illustrating one possible position of a chat window720and a chat line718relative to other aspects of the screen; although it will be understood that various windows may be dragged, re-sized, etc. by user input. The chat window720may present dialogue. In some cases, word wrap may be used and new chat may be displayed at the bottom of the window720. Hidden text may be scrolled through. In some implementations, single arrows proximate the window720may be used to scroll through text line by line. The double arrow may return to the bottom of the displayed chat. In the event that new dialogue has been posted when scrolling through older text, the double arrow may flash indicating the new text. To post text, players may enter text in chat line718then, for example, press enter. If a player receives a tell, pressing the R key may open the chat line718and present a reply tag [Reply to ] in preparation to send a reply. Referring toFIG. 7G, the table714illustrates the different formats for the different types of chat. For example, the table714includes a text color column indicating that chat may appear in different colors. For example, easy chat or filtered chat may appear in white text. A private message (Whisper/Tell) may appear as light purple. Secure chat may appear as light green. In addition, the table714includes a display column indicating that different chat may be displayed differently. For example, easy chat or filtered chat may be displayed as “[Name] says: [Text]”. A received whisper may be displayed as “[Name] whispers: [Text]”. A sent whisper may be displayed as “To [Name]: [Text]”.

While this specification contains many specifics, these should not be construed as limitations on the scope of the invention or of what may be claimed, but rather as an exemplification of preferred embodiments of the invention. Certain features that are described in this specification in the context of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be provided in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

The subject matter has been described in terms of particular variations, but other variations can be implemented and are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous. Other variations are within the scope of the following claims.

The preceding figures and accompanying description illustrate processes and implementable techniques. But system100(or its other components) contemplates using, implementing, or executing any suitable technique for performing these and other tasks. It will be understood that these processes are for illustration purposes only and that the described or similar techniques may be performed at any appropriate time, including concurrently, individually, or in combination. In addition, many of the steps in these processes may take place simultaneously and/or in different orders than as shown. Moreover, system100may use processes with additional steps, fewer steps, and/or different steps, so long as the methods remain appropriate.

In other words, although this disclosure has been described in terms of certain implementations and generally associated methods, alterations and permutations of these implementations and methods will be apparent to those skilled in the art. Accordingly, the above description of example implementations does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure.