US20080214303A1 - Method, System and Computer Program Product For Producing, Offering and Executing Recreational Application Programs - Google Patents

Method, System and Computer Program Product For Producing, Offering and Executing Recreational Application Programs Download PDF

Info

Publication number
US20080214303A1
US20080214303A1 US11/791,932 US79193205A US2008214303A1 US 20080214303 A1 US20080214303 A1 US 20080214303A1 US 79193205 A US79193205 A US 79193205A US 2008214303 A1 US2008214303 A1 US 2008214303A1
Authority
US
United States
Prior art keywords
model
event
players
player
gaming
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/791,932
Other languages
English (en)
Inventor
Timo D. Hamalainen
Marko Hannikainen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ADVANT GAMES Ltd Oy
Tampere University of Technology
Original Assignee
Tampere University of Technology
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tampere University of Technology filed Critical Tampere University of Technology
Assigned to ADVANT GAMES OY LTD. reassignment ADVANT GAMES OY LTD. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: HAMALAINEN, TIMO D., HANNIKAINEN, MARKO
Publication of US20080214303A1 publication Critical patent/US20080214303A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/34—Betting or bookmaking, e.g. Internet betting
    • A63F13/10—
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/45—Controlling the progress of the video game
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/60—Methods for processing data by generating or executing the game program
    • A63F2300/6009—Methods for processing data by generating or executing the game program for importing or creating game content, e.g. authoring tools during game development, adapting content to different platforms, use of a scripting language to create content
    • A63F2300/6018—Methods for processing data by generating or executing the game program for importing or creating game content, e.g. authoring tools during game development, adapting content to different platforms, use of a scripting language to create content where the game content is authored by the player, e.g. level editor or by game device at runtime, e.g. level is created from music data on CD

Definitions

  • the invention concerns generally the technology of producing and executing application programs that have recreational value and involve playing and/or gambling. Especially the invention involves enabling swift and systematic generation of new recreational applications of said kind, as well as swift and systematic continuing development of existing applications.
  • a betting engine program 101 comprises the means for executing the program proper. It receives registration information and bets from players and delivers responses to players through a player interface 102 . Information about games is stored in a games database 103 , and about the odds of possible outcomes of such games in an odds database 104 (which may be the same as the games database 103 ). User accounts for registered players exist in an accounts database 105 , and the bets played by the players are stored in a bets database 106 (which may be the same as the accounts database 105 ). The game organiser can start and end games, set and change the odds, and otherwise affect the operation of the recreational application program through an operator interface 107 .
  • Playing a game of chance using the program architecture shown in FIG. 1 involves for example the following steps.
  • a game organiser designs the rules of the game and the machine-readable instructions for following the rules and stores them in the games database 103 .
  • the game organiser also designs a user interface screen that informs a player about the games and its rules, and gives instructions about how to place a bet.
  • This user interface screen is stored as a part of the user interface 102 .
  • Log data about the player's actions are stored in the accounts database 105 , and the price of the bet is deducted from the player's account.
  • the bet as such is stored in the bets database 106 .
  • the betting engine 101 On the basis of the distribution of all bets stored for a particular game the betting engine 101 repeatedly calculates the odds and updates them in the odds database 104 .
  • the outcome of the game becomes known either internally within the betting engine (e.g. if the game was a virtual process such as the electronic drawing of lots) or externally so that the game organiser feeds it in through the operator interface 107 .
  • the betting engine selects the winning bets, calculates their winnings and credits the accounts of the players that had placed them. It may spontaneously announce the results to the players through the user interface 102 .
  • An objective of the present invention is to present a method and a system for systematically generating and developing gaming applications.
  • An additional objective of the invention is to present a method and a system for generating and developing dynamically adaptive gaming applications.
  • a further objective of the invention is to present a method and a system for allowing the characteristics of a gaming application to be dynamically changed on the basis of unconsciously given input from a player.
  • a yet another objective of the invention is to present a method and a system that would allow simulating and verifying a systematically generated new gaming application in a realistic and/or futuristic environment.
  • the objects of the invention are achieved by executing an event model in real time in order to represent the sequence of subevents in a target event, like a soccer game, car race or some other interesting event where a number of unpredictable minor subevents may occur. Simultaneously a gaming model is executed, which observes the developments that take place in the event model and looks for incidents that could constitute a gaming event. Additionally a player model can be parallelly involved, representing the actions of one or more players, which may be taken into account in the way in which the gaming events are made available for playing.
  • a method according to the invention is characterised by the features recited in the characterising part of the independent claim directed to a method.
  • the invention applies also to a system, which is characterised by the features recited in the characterising part of the independent claim directed to a system.
  • the invention applies also to a method for synthesizing a recreational application program for execution through players' terminals, with characteristic features as recited in the characterising part of the independent claim directed to such a method.
  • the invention applies to a computer program product for offering recreational application programs for execution through players' terminals, with characteristic features as recited in the characterising part of the independent claim directed to such a computer program product.
  • the event model there is a computer-executable process that can be designated as the event model. It is a systematic representation of a sequence of subevents that are likely to occur and that together constitute a larger scale event that is likely to raise the interest of a large group of players. However, beforehand it is not known exactly, what subevents will occur in which order in said larger scale event.
  • the operation of the event model can be easily understood by considering the event model as a state machine, although the actual implementation thereof does not need to comprise one. According to the state machine consideration, pieces of input information obtained from the event trigger transitions between states in the event model.
  • the actual event may exist in the real world, like a sports event, election or other events of general interest.
  • the actual event may have partly or completely virtual existence, like a computer game played by a number of players through a network or a fully computer-simulated sequence of subevents with no direct human interaction.
  • the implementation of the event model may be even integrated to the virtual event.
  • the gaming model there is another computer-executable process that can be designated as the gaming model. Its task is to run simultaneously with the event model, observe what happens in the event model and use its observations to consider, what kinds of games could be matched to the recent developments in the event model. For example, if the event model enters a state according to which a certain subevent is likely to occur in the immediate future, such subevent having two or more well-defined possible outcomes, the gaming model may respond by launching a game in which players may place bets on all possible outcomes of the subevent during the short time when the actual outcome is still unknown.
  • a task of the player model is to predict, how a typical player will react to a certain subevent that occurs in an event. Such a prediction may then be used to e.g. affect the way in which games are made available to the players. Properly applying a player model may assist in enhancing the emotional responsiveness of the gaming system to the players.
  • the event model, gaming model and player model may each have a library of routines at their disposal.
  • An event model may be a combination of event model routines, stored in an event models library and tailored to match a certain specific event.
  • a gaming model may use a library of possible gaming schemes, which it matches to the subevents that materialise in the event model.
  • a player model may refer to a library of statistically compiled descriptions of how players have been known to react to certain situations.
  • a coordinating entity For linking together the models explained above, a coordinating entity is needed.
  • the implementing technologies engine typically comprises e.g. interfacing routines for linking together the operation of various mutually different devices and operating systems. It may also comprise supervisory routines for ensuring smooth operation, e.g. by preventing contradictory situations where a rapidly deployed game would erroneously be made available for playing with terminals the use of which involve unacceptably long delays.
  • the implementing technologies engine has access to an implementing technologies library where various previously created routines have been preparatorily stored.
  • control interface For allowing a game organiser to exercise control over the operation of the system, it most advantageously comprises also a control interface.
  • FIG. 1 illustrates a prior art solution for a recreational application program
  • FIG. 2 illustrates certain concepts related to the invention
  • FIG. 3 illustrates an exemplary lottery part with connections
  • FIG. 4 illustrates exemplary ways of obtaining inputs from a real-life event
  • FIG. 5 illustrates an exemplary event model state machine
  • FIG. 6 illustrates another exemplary event model state machine
  • FIG. 7 illustrates an exemplary gaming model state machine
  • FIG. 8 illustrates another feature of an exemplary gaming model state machine
  • FIG. 9 a illustrates an aspect of an exemplary player model state machine
  • FIG. 9 b illustrates another aspect of an exemplary player model state machine
  • FIG. 10 illustrates schematically an aspect of an implementing technologies engine
  • FIG. 11 illustrates schematically the systematic development and synthesis of a new lottery
  • FIG. 12 illustrates schematically a composition of a gaming technology server.
  • FIG. 2 illustrates the use of certain concepts and designations that will be used in this description.
  • a lottery 201 is a multi-user gaming entity which offers a large number of players the possibility of taking part in a process where placing stakes in favour of the possible outcomes of certain well-defined future subevents may result in earning winnings.
  • Said well-defined future subevents take place in a virtual event 202 , semivirtual event 203 and/or a real-life event 204 .
  • the virtual event 202 is typically a process executed in a computer or a number of computers, where simulated subevents take place in a virtual environment.
  • a non-limiting example of a virtual event is a simulated car race, in which “cars” only exist as computational processes in the memory of a computer, and their propagation through a “track” is controlled by virtual “drivers” that also themselves are computational processes.
  • a semivirtual event 203 is a computer-executed process that depends directly on the way in which a number of users utilise their computer terminals: for example a virtual car race where the “drivers” are computer users that give control commands in essentially real time by using input means such as keypads, joysticks or steering wheel and pedal sets.
  • the real-life event 204 is typically a sports event, a musical contest, an election or other real-life occasion that raises general interest and involves subevents that may occur arbitrarily (like corners in a soccer game) and may or may not lead to certain results (like scoring a goal).
  • the game interface 205 of a game 206 can be seen as a subset of the whole concept of lottery 201 .
  • the designation “player” means in this patent application the players that participate in a lottery, while the persons the movements and actions of which constitute a real-life event 204 in sports (like the members of a soccer team) are designated as “sportsmen”.
  • the general designation “third party agents” in FIG. 2 encompasses parties that have an effect on the outcome of an event but do not participate in a lottery.
  • a non-limiting list of exemplary third party agents includes sportsmen, election candidates and computer users that do not themselves place stakes but only act e.g. as drivers of a semivirtual car race, are illustrated at the lower part of FIG. 2 .
  • the entities illustrated in FIG. 2 have mutual interactions. Starting from the right, it is usually imperative that a lottery 201 must not have any effect on how a real-life event 204 is proceeding; on the other hand the lottery 201 needs some input 211 from the real-life event, like the information that a goal was scored. Similarly a virtual event 202 and a semivirtual event 203 give input 212 and 213 to the lottery 201 , concerning the proceeding of subevents: e.g. what were the lap times of the virtual cars or where and when did a collision occur. In the case of virtual and semivirtual events it may be acceptable to let the lottery 201 have influence 214 or 215 over the event. As an example, the relative number of players from different countries that have placed bets in advance for a car race may decide, which country's racing track will be selected for the race, or the players may vote, how difficult the track should be.
  • Continuous bi-directional exchange of information 216 between a player's game and the semivirtual event 203 is essential at least concerning those occasions where the player himself is also a participant in the semivirtual event, e.g. drives a virtual car. Even if the player only participated as a “spectator” in a virtual event 202 , it is usually advantageous to arrange for a bidirectional exchange of information 217 , in order to convey real-time information from the virtual event to the player's terminal, and to let the player give direct inputs like cheering to the virtual event. If only one direction is selected for conveying information, it is most naturally means conveying information from the event to the player's terminal.
  • the return direction information 219 from the lottery 201 to the game 206 includes (but is not limited to) declaring new games, distributing game-related information like odds, and announcing results of unraveled subevents as well as the winnings earned by properly placed bets.
  • FIG. 3 illustrates an advantageous architecture for a lottery part 201 .
  • a lottery part 201 we describe its parts and the tasks of the various parts as well as their interactions on a general level. A more detailed description of the most important parts will follow later in this text.
  • the lottery part 201 comprises an event model 301 , which is a real-time process designed to represent the sequence of subevents that will take place in a virtual, semivirtual or real-life event.
  • the invention is not particularly limiting concerning the resolution or granularity at which the developments of an event are modeled in the event model 301 ; this subject will be discussed in more detail later.
  • Another section of the lottery part 201 is a gaming model 302 .
  • the task of a gaming model 302 is to follow the developments that take place in the event model 301 and to react appropriately. Since the event model 301 is a machine-executable representation of what is actually taking place in an event, we may say that the gaming model 302 observes the course of said event through the “filter” or systematic representation offered by the event model 301 . The advantage gained therethrough is that the gaming model 302 may use certain predefined, systematic criteria to determine, whether there happens something in the event model 301 that could become the subject of a game.
  • the lottery part 201 also comprises a player model 303 , the task of which is at least one of collecting information and producing predictions about the behaviour of players.
  • the player model 303 may provide means for estimating and/or controlling the emotional responsiveness of a game offered to players. This means that based on knowledge about how player(s) will react to certain game presentation, time schedule or other feature of a game, it becomes possible to optimise the way in which games are formulated for maximising the enjoyment experienced by players. Even if the player model 303 only collects information and does not actively produce predictions of player behaviour or changes to actual games, such collected information can be later used for e.g. changing the criteria that the gaming model 202 uses in evaluating the appropriateness of certain game routines to certain situations that occur in an event model. Including a player model in the lottery part 201 is not obligatory, if it is not considered necessary to make operation dependent on player behaviour or to collect information about such behaviour.
  • An implementing technologies engine 304 links together the operation of the event model 301 , the gaming model 302 and the player model 303 .
  • the implementing technologies engine 304 comprises the necessary interfaces for arranging the communication of information between the different models. It will also be responsible for arranging the communication of information between the models and the outside world, including but not being limited to receiving information from events, transmitting information to virtual and semivirtual events, and exchanging information with the players' terminals.
  • the event model 301 , the gaming model 302 and the player model 303 are all completely independent of any terminal or network technology, leaving the implementing technologies engine 304 responsible e.g. for translations between the standardised communication protocols applied within the lottery part 201 and the various communication protocols applied in the outside world.
  • control interface 305 which has bi-directional connections to all other sections of the lottery part 201 .
  • Each of the event model 301 , the gaming model 302 , the player model 303 and implementing technology engine 304 have couplings with their respective data-bases or libraries. These are the event models library 311 , the gaming models library 312 , the player models library 313 and the implementing technologies library 314 respectively.
  • the utilisation of the libraries can be illustrated with the following, non-limiting example.
  • the event is a soccer match.
  • an event model 301 a state machine that proceeds from one state to another according to inputs received from the actual event. It is impossible to say beforehand, how many subevents (like e.g. corners and penalty kicks) there will be in the event and when they will occur. Therefore there exists, in the event models library 311 , readily made component routines that are not fixed parts of the event model 301 but can be taken into use immediately when a certain triggering condition is fulfilled.
  • the event model 301 reads from the event models library 311 the appropriate component routine and starts executing it, entering first a “penalty kick pending” state where certain attributes announce, which team has got the penalty and for what reason. After the penalty kick has been delivered, the event model returns (through a “read result” action) to a normal state and stows the component routine for possible later use.
  • information about the event model entering the “penalty kick pending” state would be delivered to the gaming model 302 , which would recognise this situation as one for which a certain game could be set up. It consults the gaming models library 312 to obtain a component routine for setting up a quick betting game, in which the players must guess the result of the penalty kick situation.
  • a player model 303 could react to the information about the penalty kick pending by noting the remaining playing time in the event and reading from the player models library 313 , what is the probable reaction of players to a penalty kick at this stage of a soccer game. Information about such predicted behaviour could affect e.g. the odds that are given to the possible result alternatives in the quick betting game.
  • the implementing technologies engine 304 would check from the implementing technologies library 314 , what is the expected response time of different terminal types, and only allow the quick betting game to be announced through terminals the use of which will not involve prohibitively long delays.
  • the event model 301 , the gaming model 302 , the player model 303 and the implementing technologies model 304 it is certainly possible to construct the event model 301 , the gaming model 302 , the player model 303 and the implementing technologies model 304 to be completely self-contained so that they inherently include all possible component routines needed to arrange a lottery concerning a certain type of event.
  • the libraries 311 , 312 , 313 and 314 as a kind of design-time aids, from which the designer of such a self-contained lottery part will find the component routines that are needed to make the models sufficiently complete.
  • an event interface 306 and a player interface 307 In order to enable communication concerning the events and exchanging information with the players' terminals there are, at the disposal of the implementing technologies engine 304 , an event interface 306 and a player interface 307 . In their simplest form these are just communications connections between the lottery part 201 and an event (event interface 306 ) and the lottery part 301 and a player's terminal (player interface 307 ). Part of the features that qualify as belonging to the event interface 306 and player interface 307 may be located physically elsewhere. As an example, a player's terminal that as such constitutes the so-called enabling technology may comprise a Java-based virtual machine, on top of which runs the actual user interface software that creates the audiovisual interface that will be available for the player. Parts of such user interface software may originate from the lottery part 201 , which thus transmits executable scripts to the players' terminals.
  • an event model As an illustrative, nonlimiting example we may consider the event model as a state machine, in which transitions between states occur when certain incidents take place in the event that is the subject of modeling. If the event is a virtual or semivirtual event, it is relatively easy to derive information about any incident event therein and to convey it to an event model, since the incidents themselves only exist in the form of computer-executed processes, and they are easily complemented to include information transmission routines that transmit information to an event model whenever anything of interest takes place in the virtual or semivirtual event.
  • FIG. 4 illustrates two exemplary alternatives in a case where the real-life event is a sports event.
  • the most easily accomplished alternative is to make an observer 401 follow the event and to key in information describing the event using a terminal 402 .
  • Such an arrangement is easily set up and is adaptable to many kinds of different events, but also involves the chance of human error.
  • FIG. 4 also illustrates how the sports field 403 , the sportsmen 404 and other important elements 405 of the sports event may be equipped with sensors 406 that automatically produce information about how the sports event is proceeding. It is also possible to combine the two approaches so that information about the proceeding of the sports event is produced and transmitted to an event model both automatically and manually.
  • the principles of manual observation and sensor-based automatic monitoring are easily generalised also to other kinds of real-life events.
  • FIG. 5 illustrates a simple state machine that can be used as an event model that represents the sports event of FIG. 4 .
  • a block with rounded ends represents a state
  • a block with a triangular indent at an end represents receiving information
  • a block with an arrow-shaped end represents transmitting information.
  • a diamond-shaped block is not used in FIG. 5 but would represent a decision with more than one possible outcome, and a rectangular block would represent an action the results of which are internal to the state machine in question.
  • the state machine is first at a waiting state 501 when a match is still to begin. Receiving information at 502 about the beginning of a match causes a transition to a match in progress state 503 .
  • the state machine transmits the known end result at 505 to e.g. a gaming model or other process that needs it but did not receive it at the time when it came to the knowledge of the event model. Operation ends at a match ended state 506 .
  • FIG. 6 illustrates a slightly more refined state machine for the same purpose.
  • the waiting state 601 is similar to state 501 in FIG. 5 .
  • Receiving information at 602 about the beginning of a match causes a transition to state 603 , according to which a first half of the match is in progress.
  • the updated score of the match is transmitted (e.g. to a gaming model) at step 605 , after which follows an immediate return to state 603 .
  • Another possible transition from state 603 occurs when there is received information about the end of the first half at step 606 .
  • the intermediate score is transmitted at 607 , after which the state machine spends the break at a waiting state 608 .
  • Steps 604 ′ and 605 ′ are essentially the same as steps 604 and 605 above respectively, with the sole difference that they now occur during the second half, meaning that the return from step 605 ′ goes to state 610 and not to step 603 .
  • the end whistle at step 611 causes the final result to be transmitted at step 612 , after which operation ends at the match ended state 613 .
  • Description languages such as SDL (Specification and Description Language) exist for setting up an arrangement in which the designer of a state machine picks standardised building blocks (represented as graphics or in character form) and couples them together, after which a computer automatically fetches the corresponding source language procedures or even machine-readable instructions and compiles them into an executable program.
  • the arrangement automatically sets up the information transfer interfaces between different building blocks, so that in the description of an information transmitting step it only needs to specified, to which other step(s) in the state machine description the information is to be transmitted. Additionally or alternatively (depending on the description language) in the description of an information receiving step it needs to specified, from which other step(s) the information is to be received.
  • the automatic compiler then takes care of actually creating the proper read and write operations that are needed in order to deliver information from the correct source(s) to the correct destination(s).
  • the library is a passive collection of functionalities and rules for producing certain services.
  • the library contains the code passages that an SDL compiler would use for compiling the machine-executable representation of a state machine built in a graphical user interface.
  • the state machine is a way of arranging the execution in proper order of certain functionalities and rules, that actually are read from the library for execution.
  • the event models library may contain mutually alternative functionalities that are so close to each other that any of them could be used in principle to implement a function that was described in the state machine representation. In such a case it is advantageous if the compiler asks the designer of the event model, which functionality should be used in the machine-executable representation.
  • the state machine or other process that constitutes the event model is sufficiently independent so that its operation can be tested and verified either against a simulation program or by feeding in a large amount of historical data about known events and observing that the event model executes properly and gives the correct outputs.
  • event models running simultaneously, representing the same event.
  • the event models represented as state machines in FIGS. 5 and 6 could be used simultaneously, for example if there are different kinds of games made available to players, different types of players' terminals, different kinds of network connections, different user interfaces for players, or other factors that require different resolution or level of accuracy in the description of the event.
  • gaming principles can be classified into a number of classes, including but not being limited to
  • participant tries to perform as well as possible in a task or a series of tasks
  • a gaming model may spend time in a wait state 701 , waiting for information about the course of action that is taking place in one or more event models.
  • the gaming model receives information that a first condition has been fulfilled; for example, one of the currently executed event models has entered a state where arranging a game would basically be possible, if another condition also comes true. We assume here that it is typical to the first condition that it only remains valid for a certain known period of time. Therefore at step 703 the gaming model starts a timer.
  • the gaming model repeatedly checks whether the timer has expired. If the timer makes it to expiry before the second condition is fulfilled, a return to the wait state 701 occurs.
  • the gaming model If, however, before that the gaming model receives information showing that also the second condition has been fulfilled according to step 705 , it moves on to define a game according to certain predetermined rules at step 706 .
  • the gaming model declares the game to an implementation technologies model, which is then supposed to announce the newly declared game to appropriate player terminals.
  • the number of conditions to be fulfilled before a game can be declared is not necessarily two. It may be one, or it may be significantly more than two.
  • the timer example explained above should not be construed as limiting. Some condition that has been fulfilled once may remain in a fulfilled state forever, or until the gaming model receives explicit information showing that said condition is not fulfilled any more. Conditions may have mutual dependencies, e.g. so that a first condition is to be considered fulfilled if simultaneously a second condition is true and a third condition is false, but not if said second and third conditions are both true, or so that the first condition must be completely fulfilled if a second condition is false, but only needs to be partly fulfilled is said second condition is simultaneously true.
  • the invention does not limit the selection or formulation of conditions.
  • one exemplary set of conditions is the following: a soccer match is in progress (i.e. not in a “to come” or “ended” state), a free kick has been awarded but not yet delivered, and the sportsman selected to give the free kick is the “godchild” specifically sponsored by the lottery company.
  • a soccer match is in progress (i.e. not in a “to come” or “ended” state)
  • a free kick has been awarded but not yet delivered
  • the sportsman selected to give the free kick is the “godchild” specifically sponsored by the lottery company.
  • more or less any conditions will do as long as they define a situation in which a large number of players have essentially equal possibilities of taking part and winning in a game the outcome of which is and remains equally unknown to all such players until a cut-off moment after which bets or other kinds of participation announcements are not accepted any more.
  • the gaming model may also be responsive to other kinds of information, and information coming from other sources, than just announcements that something has happened in a certain event model.
  • a gaming model that is in a wait state 701 receives some descriptive information at step 801 .
  • a player model may announce that according to its statistical observations, a game that was recently declared and announced to players raised an exceptional amount of interest, i.e. attracted an exceptionally large number of players to participate.
  • the gaming model may interpret such an announcement as positive feedback showing that said recently declared game was a successful move, after which it changes some criteria at step 802 in a way that is likely to promote the generation and declaration of similar games in the future.
  • information about a game having only raised relatively modest interest could cause the gaming model to abstain from declaring similar games in the future.
  • a player model The purpose of a player model is to offer tools for observing, estimating and possibly controlling the emotional responsiveness of games.
  • the player model obtains or has previously obtained information about the behaviour of players in certain situations encountered in games. It is possible to subject testees to various stimuli under laboratory conditions, and observe how their emotions and reactions are reflected in parameters that could be detected and measured in a gaming situation. Such parameters include but are not limited to observed way of moving a mouse, observed mouse clicking speed and frequency, observed reaction time to various stimuluses and observed way of using a keyboard. In special cases also physiological measurements can be used, such as observing the player's pulse, eye movements or breath rate or the concentration of adrenaline in blood. From the laboratory measurements it is possible to derive universally applicable deduction rules, which can be then included in a player model.
  • FIG. 9 a illustrates schematically the operation of a simple player model state machine during a “learning” phase in which observations and/or measurements about players' reactions are used to compile statistics for later use.
  • State 901 is a wait state.
  • the player model receives new information about observed player behaviour.
  • it uses the received information to update statistics that describe typical emotional responses of a player to certain conditions.
  • it may transmit some key figures of the updated statistics to some other process that may need them, after which there occurs a return to the wait state 901 .
  • the player model will receive input from a user interface, indicating e.g. the most recently observed distribution of some parameter values of the kind mentioned above.
  • the player model will generate standardised outputs for the use of the other models, which outputs describe, what deductions the player model has made about the most recent developments in emotional responsiveness of the game.
  • the player model may also receive inputs from the event and gaming models.
  • a player model may refer to a database of previously produced laboratory measurements in order to estimate the emotional effect of such combination of subevents: a penalty kick awarded in a dead heat situation with only five minutes remaining in the match is likely to cause a differential emotional response in players than a penalty kick during the very first minutes of a match or in a match the score of which is already clearly in favour of one team.
  • FIG. 9 b illustrates schematically the operation of a simple player model state machine during an “operational” phase in which it responds dynamically to conditions and/or combinations of conditions observed in an event model or a gaming model by providing estimates about player behaviour.
  • State 901 is again a wait state.
  • the player model receives an announcement of an observed condition or a combination of conditions in an event model or a gaming model.
  • the player model maps said condition or combination of conditions into estimated player behaviour, for example by looking for a best match between a current condition and a previously used test condition, with reference to which there has been stored statistical information about player behaviour that was observed in a laboratory environment.
  • One of the known suitable technical means for finding best matches of this kind is a neural network, although also other technical means can be applied.
  • the player model After having found some information about the most probable emotional response of a player to the current condition or combination of connections the player model transmits that information to e.g. a gaming model at step 914 , after which there occurs a return to the wait state 90
  • a player model could monitor the behaviour of an individual player or a limited number of players in order to determine, whether said behaviour indicates excessive addiction or compulsion to playing.
  • a positive indication could be used to trigger limiting action, so that the system would not allow the player(s) concerned to play more than up to a certain limit.
  • a further possibility is to use an estimate of players' excitement for tuning the odds or other rules of a game.
  • the implementing technologies model is where the actual generation and storing of executable computer code takes place, utilising the higher-level definitions obtained from the other models.
  • a more distributed approach would be to let the event model, the gaming model and the player model to generate their own machine-executable codes, and only use the implementing technologies model as an entity that arranges the communication of information between the other models.
  • the implementing technologies model is responsible for consolidating the capabilities of the other components and the requirements placed to a game and the whole lottery part.
  • the components selected for a certain implementation should have sufficient capacity: for example a calculationally very intensive routine can only be taken to constitute a part of an implementation if it can be ascertained that the available computing capacity will always be sufficient for executing said routine at all required instances.
  • security and confidentiality should be considered: an implementation should include e.g. necessary encryption and decryption routines for arranging cryptographically protected communication where needed.
  • the implementing technologies model may also consider cost aspects, e.g. so that an implementation will not be allowed if it would involve causing excessive cost.
  • Technology components that are available to the implementing technologies model may include, among others, the following:
  • the implementing technologies model should include rules for verifying the technical compatibility of all selected components and functionalities, as well as for arranging their mutual hierarchy and relations. It must not allow setting up implementations involving significant technical risks for malfunctioning, or implementations where component procedures would be contradictory to each other. Additionally the implementing technologies model may consider the quality of playing experienced by players, expressed e.g. as robustness against disruptions in communication and/or minimisation of delays. If the successful playing of a game depends on providing responses fast enough, the implementation technologies model should not allow announcing it to be played with terminals that involve, or the communication connections to which involve, significant risk of excessive delays.
  • FIG. 10 is an exemplary composition and model of operation for an implementing technologies model.
  • the progress of events is determined by a technologies state machine 1001 , which is a programmed computer-executable process that proceeds from state to state, accepting inputs and producing outputs according to a well-defined causal chain.
  • a technologies state machine 1001 which is a programmed computer-executable process that proceeds from state to state, accepting inputs and producing outputs according to a well-defined causal chain.
  • component processes of which four examples are shown in FIG. 10 .
  • An odds calculating component 1011 exists for calculating odds, and is coupled to the technologies state machine 1001 through a component interface 1012 , which standardizes the communication between the component and the technologies state machine 1001 so that for example a component can be exchanged to an updated version without having to touch the technologies state machine's side of the interface.
  • FIG. 10 shows the exemplary existence of an SSL connection component 1031 , which—with its component interface 1032 —is responsible for setting up a secured connection over an untrusted network, as well as a TCP/IP connection component 1041 , which is meant to implement TCP/IP based parts of connections. Also the TCP/IP connection component 1041 has a component interface 1042 .
  • the most straightforward way of arranging functional dependencies is the one schematically shown in FIG. 10 , i.e. the one in which the technologies state machine 1001 is the immediate user of all component processes.
  • connection maintenance component governs subcomponents meant for implementing various mutually alternative or augmenting protocols, and the technologies state machine only needs to communicate with the connection maintenance component.
  • FIG. 11 illustrates schematically a development and synthesis process. It begins from an idea 1101 of what a new lottery should be like. Typically the next step is the development of an event model at step 1102 , utilising knowledge about existing event model component routines in an event models library 311 . The next step 1102 involves developing a gaming model, typically by adapting existing gaming model component routines from a gaming models library 312 to be associated with suitable subevents that may take place in the event model.
  • a player model is developed and bound to the event model and gaming model(s) developed at steps 1102 and 1103 , again by utilising knowledge about player model component routines existing in a player models library 313 whenever possible.
  • an implementing technologies model is developed to bind together the event model, gaming model and player model developed earlier.
  • An implementing technologies library 314 is used as an aid. Assuming that the centralised approach mentioned earlier is used, the event models library 311 , the gaming models library 312 and the player models library 313 contain more or less human-understandable rules and definitions of the appropriate component routines, while the actual .exe files or corresponding computer-executable instructions appear in the implementing technologies library 314 .
  • steps 1102 , 1103 and 1104 involved working mostly with said human-understandable rules and definitions
  • steps 1102 , 1103 and 1104 involved working mostly with said human-understandable rules and definitions
  • step 1105 the corresponding computer-executable instructions are fetched and linked together into an entity that finally constitutes the synthesized new lottery obtained at step 1106 .
  • All and any of steps 1102 , 1103 , 1104 , 1105 and 1106 may include verification, simulation, testing and comparison against user experiences, as is graphically illustrated as block 1111 in FIG. 11 .
  • the development flow appears as a one-way road in FIG. 11 , this should not be construed as a limitation; the development work may well include backward steps, if e.g. during the development of a gaming model it is found that a slightly differently formulated event model would make it easier to adapt a pre-existing gaming model component routine for use in the new lottery.
  • FIG. 12 illustrates an example composition of a server arrangement used to run a lottery according to an embodiment of the invention.
  • means 1201 for executing the state machines that represent the event model, gaming model, player model and implementing technologies model.
  • means 1202 for executing core components of the server arrangements, like internal data transfer.
  • means 1203 for performing server administration, such as memory allocation and maintenance, as well as means 1204 for performing other processes.
  • Communications with other computer devices require the implementation of various protocols, which is taken care of by means 1205 for communications-related component execution.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Economics (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • General Health & Medical Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Display Devices Of Pinball Game Machines (AREA)
US11/791,932 2004-12-02 2005-11-30 Method, System and Computer Program Product For Producing, Offering and Executing Recreational Application Programs Abandoned US20080214303A1 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FI20041563 2004-12-02
FI20041563A FI119858B (fi) 2004-12-02 2004-12-02 Menetelmä, järjestelmä ja tietokoneohjelma viihteellisten sovellusohjelmien tuottamiseksi, tarjoamiseksi ja ajamiseksi
PCT/FI2005/000518 WO2006058957A1 (en) 2004-12-02 2005-11-30 Method, system and computer program product for producing, offering and executing recreational application programs

Publications (1)

Publication Number Publication Date
US20080214303A1 true US20080214303A1 (en) 2008-09-04

Family

ID=33547936

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/791,932 Abandoned US20080214303A1 (en) 2004-12-02 2005-11-30 Method, System and Computer Program Product For Producing, Offering and Executing Recreational Application Programs

Country Status (5)

Country Link
US (1) US20080214303A1 (fi)
EP (1) EP1839258A4 (fi)
FI (1) FI119858B (fi)
NO (1) NO20072760L (fi)
WO (1) WO2006058957A1 (fi)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080242949A1 (en) * 2007-03-30 2008-10-02 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Computational user-health testing
US20090258685A1 (en) * 2007-10-10 2009-10-15 Gabriel Gaidos Method for merging live sports game data with Internet based computer games
US20100331065A1 (en) * 2008-03-07 2010-12-30 Virtually Live Limited Media System and Method
US20130029735A1 (en) * 2008-03-07 2013-01-31 Virtually Live Ltd. Media System and Method
CN104778085A (zh) * 2015-03-25 2015-07-15 广州多益网络科技有限公司 一种手游的游戏对战处理方法及装置
US9536378B2 (en) 2012-01-13 2017-01-03 Igt Canada Solutions Ulc Systems and methods for recommending games to registered players using distributed storage
US9558625B2 (en) 2012-01-13 2017-01-31 Igt Canada Solutions Ulc Systems and methods for recommending games to anonymous players using distributed storage
US10042748B2 (en) 2012-01-13 2018-08-07 Igt Canada Solutions Ulc Automated discovery of gaming preferences
US11468744B2 (en) * 2020-09-30 2022-10-11 Adrenalineip Wager sharing and invitation method

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009061172A1 (en) * 2007-09-21 2009-05-14 Roward Trade Computer program product and computersystem

Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4339798A (en) * 1979-12-17 1982-07-13 Remote Dynamics Remote gaming system
US6080063A (en) * 1997-01-06 2000-06-27 Khosla; Vinod Simulated real time game play with live event
US6204862B1 (en) * 1990-06-25 2001-03-20 David R. Barstow Method and apparatus for broadcasting live events to another location and producing a computer simulation of the events at that location
US20020054088A1 (en) * 1999-05-28 2002-05-09 Erkki Tanskanen Real-time, interactive and personalized video services
US20030008711A1 (en) * 2001-07-05 2003-01-09 Dana Corbo Method and system for providing real time sports betting information
US6616529B1 (en) * 2000-06-19 2003-09-09 Intel Corporation Simulation and synthesis of sports matches
US6722980B2 (en) * 1999-04-30 2004-04-20 Asip Holdings Inc Wagering system
US20040204216A1 (en) * 2003-04-10 2004-10-14 David Schugar Casino games directed to betting on progressions
US20050059495A1 (en) * 2003-09-15 2005-03-17 Youbet.Com, Inc. System and method for relaying race information
US20070099703A1 (en) * 2003-09-16 2007-05-03 Is-Innovation Systems Ltd Massive role-playing games or other multiplayer games system and method using cellular phone or device
US20070265089A1 (en) * 2002-05-13 2007-11-15 Consolidated Global Fun Unlimited Simulated phenomena interaction game
US20090088232A1 (en) * 2004-06-28 2009-04-02 Cfph Llc System and method for providing bets regarding intermediate points in a race event
US7566268B2 (en) * 2004-04-29 2009-07-28 Cfph, L.L.C. Roulette game based on results from a sporting event
US7711628B2 (en) * 2004-03-05 2010-05-04 Cantor Index Llc System and method for offering intraday wagering in a financial market environment

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AUPR198800A0 (en) * 2000-12-08 2001-01-11 Structured Data Systems Pty Ltd Race simulation system and method
US6921331B2 (en) * 2001-04-19 2005-07-26 Cyberscan Technology, Inc. Methods and systems for electronic virtual races
WO2003095050A2 (en) * 2002-05-13 2003-11-20 Consolidated Global Fun Unlimited, Llc Method and system for interacting with simulated phenomena

Patent Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4339798A (en) * 1979-12-17 1982-07-13 Remote Dynamics Remote gaming system
US6204862B1 (en) * 1990-06-25 2001-03-20 David R. Barstow Method and apparatus for broadcasting live events to another location and producing a computer simulation of the events at that location
US6080063A (en) * 1997-01-06 2000-06-27 Khosla; Vinod Simulated real time game play with live event
US6726567B1 (en) * 1997-01-06 2004-04-27 Vinod Khosla Simulated real time game play with live event
US6722980B2 (en) * 1999-04-30 2004-04-20 Asip Holdings Inc Wagering system
US7451401B2 (en) * 1999-05-28 2008-11-11 Nokia Corporation Real-time, interactive and personalized video services
US20020054088A1 (en) * 1999-05-28 2002-05-09 Erkki Tanskanen Real-time, interactive and personalized video services
US6616529B1 (en) * 2000-06-19 2003-09-09 Intel Corporation Simulation and synthesis of sports matches
US20030008711A1 (en) * 2001-07-05 2003-01-09 Dana Corbo Method and system for providing real time sports betting information
US20070265089A1 (en) * 2002-05-13 2007-11-15 Consolidated Global Fun Unlimited Simulated phenomena interaction game
US20040204216A1 (en) * 2003-04-10 2004-10-14 David Schugar Casino games directed to betting on progressions
US20050059495A1 (en) * 2003-09-15 2005-03-17 Youbet.Com, Inc. System and method for relaying race information
US20070099703A1 (en) * 2003-09-16 2007-05-03 Is-Innovation Systems Ltd Massive role-playing games or other multiplayer games system and method using cellular phone or device
US7711628B2 (en) * 2004-03-05 2010-05-04 Cantor Index Llc System and method for offering intraday wagering in a financial market environment
US7566268B2 (en) * 2004-04-29 2009-07-28 Cfph, L.L.C. Roulette game based on results from a sporting event
US7637807B2 (en) * 2004-04-29 2009-12-29 Cfph, L.L.C. System and method for mapping results from sporting events to game inputs
US20090088232A1 (en) * 2004-06-28 2009-04-02 Cfph Llc System and method for providing bets regarding intermediate points in a race event

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080242949A1 (en) * 2007-03-30 2008-10-02 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Computational user-health testing
US20090258685A1 (en) * 2007-10-10 2009-10-15 Gabriel Gaidos Method for merging live sports game data with Internet based computer games
US20170182421A1 (en) * 2008-03-07 2017-06-29 Virtually Live (Switzerland) Gmbh Media system and method
US20100331065A1 (en) * 2008-03-07 2010-12-30 Virtually Live Limited Media System and Method
CN101960820A (zh) * 2008-03-07 2011-01-26 虚拟直播有限公司 媒体系统与方法
US8128469B2 (en) * 2008-03-07 2012-03-06 Virtually Live Ltd. Media system and method
US20130029735A1 (en) * 2008-03-07 2013-01-31 Virtually Live Ltd. Media System and Method
US10272340B2 (en) 2008-03-07 2019-04-30 Virtually Live (Switzerland) Gmbh Media system and method
US9968853B2 (en) * 2008-03-07 2018-05-15 Virtually Live (Switzerland) Gmbh Media system and method
US9576330B2 (en) * 2008-03-07 2017-02-21 Virtually Live (Switzerland) Gmbh Media system and method
US9558625B2 (en) 2012-01-13 2017-01-31 Igt Canada Solutions Ulc Systems and methods for recommending games to anonymous players using distributed storage
US9536378B2 (en) 2012-01-13 2017-01-03 Igt Canada Solutions Ulc Systems and methods for recommending games to registered players using distributed storage
US10042748B2 (en) 2012-01-13 2018-08-07 Igt Canada Solutions Ulc Automated discovery of gaming preferences
US10068422B2 (en) 2012-01-13 2018-09-04 Igt Canada Solutions Ulc Systems and methods for recommending games to anonymous players using distributed storage
CN104778085A (zh) * 2015-03-25 2015-07-15 广州多益网络科技有限公司 一种手游的游戏对战处理方法及装置
US11468744B2 (en) * 2020-09-30 2022-10-11 Adrenalineip Wager sharing and invitation method
US11861986B2 (en) 2020-09-30 2024-01-02 Adrenalineip Wager sharing and invitation method

Also Published As

Publication number Publication date
WO2006058957A1 (en) 2006-06-08
EP1839258A1 (en) 2007-10-03
FI119858B (fi) 2009-04-15
NO20072760L (no) 2007-08-31
EP1839258A4 (en) 2009-07-01
FI20041563A0 (fi) 2004-12-02

Similar Documents

Publication Publication Date Title
US20080214303A1 (en) Method, System and Computer Program Product For Producing, Offering and Executing Recreational Application Programs
Togelius et al. What is procedural content generation? Mario on the borderline
Togelius et al. The 2009 mario ai competition
AU2008296581B2 (en) Return-driven casino game outcome generator
KR20070052493A (ko) 게이머의 플레이 패턴 분석을 통한 게임 가이드 정보 제공방법 및 이를 구현하는 시스템
US20040043806A1 (en) Online vehicle collection and play activity
US20060281509A1 (en) Action video game for wagering where the player's reward to a challenge is determined by combining the player's skill in facing the challenge with the realization of a randomly generated event, where the likelihood of each possible realization of the random event depends on the player's skill
KR20040083515A (ko) 전자 게임 환경에서의 가상 ｉｐｒ 시스템
CN109448269A (zh) 对等软件平台
JP5945266B2 (ja) 交流型玩具
CN101408913A (zh) 多个争夺互联网网站的在线参与者间的交互式对战视频游戏
WO2018018148A1 (en) Method and system for executing and managing event-based games on a mobile device
CN116747521B (zh) 控制智能体进行对局的方法、装置、设备及存储介质
Intawong et al. A Framework of Developing Mobile Gamification to Improve User Engagement of Physical Activity: A Case Study of Location-Based Augmented Reality Mobile Game for Promoting Physical Health.
Green et al. Game Mechanic Alignment Theory
CN1649651A (zh) 在线车辆收集和游戏活动
Teófilo et al. Simulation and performance assessment of poker agents
CN111211961A (zh) 游戏信息提供系统
KR20070019441A (ko) 인터넷 기반의 감성로봇
Machado Aplpication developmente over IoT platform Thingworx
Anttonen Online multiplayer on mobile game
Zook Automated iterative game design
Stephens et al. Balancing Multiplayer Games across Player Skill Levels using Deep Reinforcement Learning.
Liébana VGDL and the GVGAI Framework
KR20240120004A (ko) 의사결정트리 알고리즘을 이용한 게임 인공지능 설명 및 게임 서비스 제공 시스템

Legal Events

Date Code Title Description
AS Assignment

Owner name: ADVANT GAMES OY LTD., FINLAND

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HAMALAINEN, TIMO D.;HANNIKAINEN, MARKO;REEL/FRAME:020213/0906

Effective date: 20070925

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION