The present invention relates to the field of online gaming and more particularly, to online gaming incorporating a lotterized and/or wagering aspect therein.
An online game is a game played over some form of a computer network, such as the Internet. The expansion of online gaming has reflected the overall expansion of computer networks from small local networks to the Internet and the growth of Internet access itself. Online games can range from simple text based games to games incorporating complex graphics and virtual worlds populated by many players simultaneously. Many online games have associated online communities, making online games a form of social activity beyond single player games.
A lottery is a form of gambling which involves the drawing of lots for a prize and it may come in various formats. For example, the prize can be a fixed amount of cash or goods. Alternatively, the prize may be a fixed percentage of the receipts, such as a “50-50” draw, where the prize is 50% of the revenue.
Other types of gambling games are those where money is staked on the outcome of a game at least partly based on skill, such as poker, blackjack, and billiards.
The demographics targeted and attracted to online games vs. lottery games vs. other types of gambling games vary widely. Providers of such games are always looking for ways to increase the population segments that will show an interest in either type of game.
There is described herein an interactive game having both lotterized and skill-based wagering aspects embedded therein. A skill-based game is used to provide players with the challenge and entertainment value that they are accustomed to experiencing in popular mobile games, while adding the possibility of collecting real world winnings via lotteries and other forms of wagering.
In accordance with a first broad aspect, there is provided a system for executing an interactive video game having a lotterized component and a skill-based wagering component, the system comprising: at least one computer server communicable with at least one client computing device over a network, the server having a processor and a memory; a gaming engine module stored on the memory and executable by the processor, the gaming engine module having program code that when executed, generates an interactive game play instance playable on the client computing device; a lottery services module stored on the memory and executable by the processor, the lottery services module having program code that when executed, conducts a real world lottery transaction within the game play instance; and a skill-based wagering module stored on the memory and executable by the processor, the skill-based wagering module having program code that when executed, manages wagers placed on an outcome of the game play instance for a chance to win real world money, the outcome being at least partially determined on the basis of player skill.
In one embodiment the game play instance is playable in a single player mode and in a multi-player mode, the real world lottery transaction is performed within the game play instance in the single player mode, and the wagered virtual currency is allotted to a winner of the game play instance in the multi-player mode. In an alternative embodiment, the lotterized component and the skill-based component are both available in single player mode and multi-player mode.
In accordance with a second broad aspect, there is provided a computer-implemented method for providing an interactive video game having a lotterized component and a skill-based wagering component, the method comprising executing on a processor program code for: generating an interactive game play instance playable on a client computing device; conducting a real world lottery transaction within the game play instance; and managing wagers on the outcome of the game play instance for a chance to win real world money, the outcome being at least partially determined on the basis of player skill.
In accordance with another broad aspect, there is provided a computer readable medium having stored thereon program code executable by a processor for providing an interactive video game having a lotterized component and a skill-based wagering component, the program code executable for: generating an interactive game play instance playable on a client computing device; conducting a real world lottery transaction within the game play instance; and managing wagers on the outcome of the game play instance for a chance to win real world money, the outcome being at least partially determined on the basis of player skill.
In this specification, the term “credits” is intended to mean a virtual currency used in a virtual world to purchase virtual items, without possibility for conversion to a real world currency. The term “tokens” refers to a virtual currency applicable in a virtual world in a wagering scenario (lottery or other types of wagering) to win real world prizes. The term “win opportunities” refers to instant chances to win a real world prize via a lottery or other type of wagering game, and/or future chances to enter a draw to win a real world prize. The term “lottery” refers to a draw with a randomly or pseudo-randomly determined outcome. The term “skill-based wager” is used for gambling games where the outcome is at least partly skill-based.
Further features and advantages of the present invention will become apparent from the following detailed description, taken in combination with the appended drawings, in which:
It will be noted that throughout the appended drawings, like features are identified by like reference numerals.
There is described herein an interactive online game that may be a turn-based game of skill and strategy. Players attack each other and strategically place fortifications to protect their own base from attack. Each player takes turns attacking an opponent and the victor wins a portion of the opponent's resources.
When the player begins the game 102, he is asked to purchase credits 104. Credits are a virtual currency used to purchase elements necessary to play the game, such as fortifications and weapons. Credits cannot be converted into real dollars and have a value only in the virtual world of the game. With credits, the player may choose to enter practice mode 106 or to purchase tokens 108.
Practice mode is a reduced form of the game used to give the player an idea of what game play is like and how the lotterized aspects are embedded in the game, without providing the lotterized aspects. Various other restrictions may be imposed on the practice mode version of the game, such as limited play time, limited graphics, limited elements available for purchase, etc.
Tokens are a virtual currency different from credits in that they are used for the lotterized aspects of the game. They may be converted to real dollars at an exchange rate set by the game operator. In some embodiments, a predetermined amount is subtracted from a pot of tokens and the remaining amount is allotted to the winning player. Tokens are required in order to play the full version of the game, either in single player mode 110 or in challenge mode 112 (also referred to as multi-player mode).
Single player made 110 is illustrated in the flow chart of
Before beginning the actual game, a given amount of tokens are wagered 202. The amount required may be set by the game operator or the player may be given free reign to select an amount to wager. In yet another embodiment, the amount wagered may be selected from a list of fixed amounts, such as 5 tokens, 10 tokens, and 15 tokens. The amount wagered may impact the potential winnings from the lotterized aspect of the game. For example, a wager of 5 tokens may result in a potential gain of 15 tokens, while a wager of 10 tokens may result in a potential gain of 25 tokens.
Once wagering has been settled, the player may purchase fortifications and weapons to play the game 204 using the credits previously purchased. The rules and regulations guiding this purchase and how the elements are used are dictated by the rules of the game. Changes in the rules of the game may impact how these elements are purchased, which types of elements are available, and how they are used within the game.
The player may then participate in the actual game 206. Exemplary game play for single player mode is illustrated in
A timer may be used to indicate how long the player has to complete his set-up. Once the time expires, the game transitions to an attack or defense screen. When in attack mode, the player must launch a weapon at one of the opponent's fortifications 304. A timer may again be used to limit the time available to the player to launch the weapon. In this case, if the player fails to launch a weapon before the time expires, he forfeits his turn. The timer is used as a means to keep the player engaged in the game and also discourages the player from leaving a game that he is losing.
In single player mode, the lotterized aspects are embedded at this stage of the game. In any one game, the player has a given number of attacks available. For example, in one embodiment, the player is allowed six attacks on his opponent, and the opponent will attack the player six times. Any one of the six attacks launched by the player may result in a lotterized win. The game operator may randomly allocate a lottery win to any one of the launches. Alternatively, more than one launch may result in a lottery win. Lottery wins are independent of the skill of the player as the decision regarding which launch is a lottery win and which launch is not a lottery win is made arbitrarily. Therefore, any launch made by the player may result in winning tokens 306.
After the player launches a weapon, the opponent launches a weapon aimed at the player's fortifications 308. As indicated above, the opponent is controlled by a computer in single player mode. The player and the computer take turns launching their weapons until there are no more weapons or until one of the two has destroyed all of the fortifications of the other. If the player wins, then he may collect his winnings 310. In the case of a loss, no winnings are earned and in some instances, credits may even be lost 312. The tokens won by the player during the lotterized aspects of the game may be independent from the outcome of the game. A launch that results in a miss may be a lotterized win, and the player may have obtained one or more lotterized wins and still have lost the battle. In some instances, the tokens wagered before the game in order to play may result in tokens winnings if the player wins the game. Alternatively, these tokens are simply lost and are considered a cost of playing the game.
Referring back to
In one embodiment, the attack of the player on the opponent in single player mode has an impact on the opponent's game, even though they do not actively participate in the battle. When selected as an opponent, the player on the receiving end of the attack is likely not in the game and possibly not even online. For this reason, they may not be aware that they are being attacked. However, when logging into the game after the attack, the opponent will then realize that he or she has been attacked and that some damage has been incurred. If desired, the game operator may set the game so that the damage incurred by an attack from a player in single player mode is far less substantial than the damage incurred by the player when participating actively in the game in challenge mode. In this embodiment, the game still progresses, even when the player is not actively battling opponents.
Once the opponent selected, the player sends out a challenge to the other player(s) 402. In addition, the player indicates a wager in the form of tokens 404. This is the skill-based wagering aspect of the challenge mode as any winnings collected from this battle may be converted to real money, and the winner of the wager is determined by the outcome of the game. In some embodiments, skill-based wagering may also take place in single player mode, with the player battling the computer.
In challenge mode, the challenged player may receive an alert, such as a pop-up or notification, to join the game and match the challenger's stake. The challenged player may also suggest an alternate stake if the one proposed is too high or too low for him. Once the two agree on a wager, the challenger receives a notice that the challenge has been accepted 406. In this mode, winning real money is dependent at least in part on player skill and ability.
Similarly to single player mode, the players must each purchase fortifications and weapons using credits 408. They then play the game 410 and the winner obtains the tokens in play.
The first player launches a weapon at the second player's fortifications 504. This is followed by the second player launching a weapon at the first player's fortifications 506. These two steps are repeated until a winner emerges. In one embodiment, the challenge ends when one player's fortifications are entirely destroyed. Alternatively, the challenge ends when the players run out of weapons and the loser is the one with the greatest damage to his fortifications. In yet another alternative, the battle is time-limited and when time runs out, the loser is the one with the greatest damage to his fortifications. The winning player collects the wager of tokens 508.
In one embodiment, the lotterized aspect of the game found in single player mode may also be provided in challenge mode. For example, in addition to the potential winnings obtained by winning the battle, one or more of each player's weapon launches may result in a win opportunity via an instant lottery draw or an opportunity to participate in a future lottery draw. Other types of instant prizes may also be provided to the player via the lotterized win opportunities. In an alternative embodiment, the lotterized win opportunities are only available in single player mode.
In one embodiment, the players are each allotted a given amount of credits to buy armaments for the battle in challenge mode. These credits do not live beyond the scope of the challenge and are only used for this challenge. Alternatively, the players must use their own credits to purchase the elements necessary to participate in the battle.
In one embodiment, the players play at a randomly selected level. Alternatively, the level of one of the two players may dictate the level at which the challenge battle takes place. Also alternatively, the players may be allowed to select which level to play at. For example, this may be selected by the challenger at the time of sending the challenge and be part of the conditions of the challenge that are to be accepted by the player receiving the challenge.
At this stage of the game, the player will have already purchased a set of weapons. When setting up his game board, the player associates a given purchased weapon with a given purchased fortification. Each weapon is hidden from attack in a fortification. When the player selects a weapon for launch 602, he is choosing one of the weapons in one of the fortifications from his game set-up.
After selecting the weapon 602, the player may launch the weapon 606. In one embodiment, the strength of the launch is determined using a power bar. The player pulls down on the power bar 604 to maximize damage caused by the attack. Alternative methods of maximizing damage may also be provided, such as “purchasing” a damage level using a number of credits or tokens, and randomly assigning a power level to any given launch. Once the weapon has been launched 606, the screen changes from the player's own set-up to the opponent's set-up. The player must aim for a given fortification 608 on the opponent's set-up. In one embodiment, aiming is done using an accelerometer of the mobile device on which the player is playing the game. The accelerometer rotates on three different axes, namely x, y, and z. The weapon may be directed at a fortification by moving the mobile device in one or more axis, or by rotating the device about one or more axis. In an alternative embodiment, the player may use a pointer (such as a mouse) or his finger (on a touch screen) to select one of the opponent's fortifications.
Referring to
The server 900 comprises, amongst other things, a plurality of applications 906a . . . 906n running on a processor 904, the processor being coupled to a memory 902. It should be understood that while the applications 906a . . . 906n presented herein are illustrated and described as separate entities, they may be combined or separated in a variety of ways.
One or more databases (not shown) may be integrated directly into memory 902 or may be provided separately therefrom and remotely from the server 900. In the case of a remote access to the databases, access may occur via any type of network 908, as indicated above. The various databases described herein may be provided as collections of data or information organized for rapid search and retrieval by a computer. They are structured to facilitate storage, retrieval, modification, and deletion of data in conjunction with various data-processing operations. They may consist of a file or sets of files that can be broken down into records, each of which consists of one or more fields. Database information may be retrieved through queries using keywords and sorting commands, in order to rapidly search, rearrange, group, and select the field. The databases may be any organization of data on a data storage medium, such as one or more servers.
In one embodiment, the databases are secure web servers and Hypertext Transport Protocol Secure (HTTPS) capable of supporting Transport Layer Security (TLS), which is a protocol used for access to the data. Communications to and from the secure web servers may be secured using Secure Sockets Layer (SSL). An SSL session may be started by sending a request to the Web server with an HTTPS prefix in the URL, which causes port number “443” to be placed into the packets. Port “443” is the number assigned to the SSL application on the server. Identity verification of a user may be performed using usernames and passwords for all users. Various levels of access rights may be provided to multiple levels of users.
Alternatively, any known communication protocols that enable devices within a computer network to exchange information may be used. Examples of protocols are as follows: IP (Internet Protocol), UDP (User Datagram Protocol), TCP (Transmission Control Protocol), DHCP (Dynamic Host Configuration Protocol), HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol), Telnet (Telnet Remote Protocol), SSH (Secure Shell Remote Protocol), POP3 (Post Office Protocol 3), SMTP (Simple Mail Transfer Protocol), IMAP (Internet Message Access Protocol), SOAP (Simple Object Access Protocol), PPP (Point-to-Point Protocol), RFB (Remote Frame buffer) Protocol.
The memory 902 accessible by the processor 904 receives and stores data. The memory 902 may be a main memory, such as a high speed Random Access Memory (RAM), or an auxiliary storage unit, such as a hard disk, a floppy disk, or a magnetic tape drive. The memory may be any other type of memory, such as a Read-Only Memory (ROM), or optical storage media such as a videodisc and a compact disc.
The processor 904 may access the memory 902 to retrieve data. The processor 904 may be any device that can perform operations on data. Examples are a central processing unit (CPU), a front-end processor, a microprocessor, a graphics processing unit (GPUNPU), a physics processing unit (PPU), a digital signal processor, and a network processor. The applications 906a . . . 906n are coupled to the processor 904 and configured to perform various tasks as explained below in more detail. An output may be transmitted to the client device 910.
A management module 1012 is illustrated as comprising a player account manager 1008 and a transaction module 1010. The transaction module 1010 is involved in the real world transactional aspects of the game. Real world transactions are involved when players purchase virtual currencies and when players are awarded cash or other real world prizes via the integrated lotteries and wagering. Therefore, the transaction module 1010 interacts with the lottery services module 1004 and the skill-based wagering module 1006 to manage the transactions. The transaction module 1010 also interacts with the player account manager 1008. The player account manager 1008 is responsible for managing player account functions, such as creating a player account, validating an existing player's login and password or a new player's eligibility to play the game, suspending a player's account, activating a player account, creating a player profile, viewing a player profile, viewing a current balance of a player's real money in a player account, updating a current balance of a player's real money account, and updating a player's virtual ranking/status.
The gaming engine module 1002 is a flexible and reusable software platform which provides core functionalities needed to develop a game application. This module may be responsible for all aspects of the lotterized video game that relate directly to the interactive game, namely the battles.
The lottery services module 1004 is responsible for all aspects of the lotterized video game that relate directly to the lotterized features incorporated into the interactive game.
The following is an exemplary description of the interaction of the various modules of
To start a new game, the player must purchase virtual currency. The transaction module 1010 will perform a financial transaction and issue the requested virtual currency. The player account database 1406 is updated with this new information once the virtual currency has been purchased.
As the player plays the video interactive game, the gaming engine module 1002 continues to provide the appropriate graphics. simulate various environments, and apply gaming logic to allow the player to progress in the game. When a win opportunity is presented, the lottery services module 1004 will perform lottery draws and award real world prizes accordingly. The transaction module 1010 will be involved in the transactional aspects of the lottery draws and the player account manager 1008 is updated with any new information to the player's account. When a wager is placed on the outcome of a game, the wagering module 1006 manages the exchanges between the players to agree on the wager amount, locks in the wager amount, and allocates the winnings to the winner of the battle.
While illustrated in the block diagrams as groups of discrete components communicating with each other via distinct data signal connections, it will be understood by those skilled in the art that the present embodiments are provided by a combination of hardware and software components, with some components being implemented by a given function or operation of a hardware or software system, and many of the data paths illustrated being implemented by data communication within a computer application or operating system. The structure illustrated is thus provided for efficiency of teaching the present embodiment.
It should be noted that the present invention can be carried out as a method, can be embodied in a system, a computer readable medium or an electrical or electro-magnetic signal. The embodiments of the invention described above are intended to be exemplary only. The scope of the invention is therefore intended to be limited solely by the scope of the appended claims.
The present application claims priority under 35 USC 119(e) of U.S. Provisional Patent Application No. 61/492,702, filed on Jun. 2, 2011, U.S. Provisional Patent Application No. 61/492,644, filed on Jun. 2, 2011, and U.S. Provisional Application No. 61/430,889, filed on Jan. 7, 2011, the contents of which are hereby incorporated by reference.
Number | Date | Country | |
---|---|---|---|
61430889 | Jan 2011 | US | |
61492644 | Jun 2011 | US | |
61492702 | Jun 2011 | US |