FI119858B - A method, system, and computer program for producing, providing, and running entertaining application programs - Google Patents

Description

Method, system and computer program for producing, providing and running entertaining application programs - Förfarande, system and data program för att producera, erbjuda och köra underhällande tillämpnings-programvara 5

The invention relates generally to the production and execution of software programs of entertainment value that involve gaming and / or gambling. In particular, the invention relates to the provision of rapid and systematic development of such new entertainment applications and the rapid and systematic development of existing applications.

Figure 1 schematically illustrates a typical prior art entertainment application with a betting or gambling aspect. The betting machine program 101 includes means for executing the actual program. It receives registration information and bets from players and sends responses to players via the Fri-15 broadband 102. The game database 103 stores game information, and the odds database 104 (which may be the same as the game database 103) stores information on the odds of the possible outcomes of the games. Registered players' user accounts are in the account database 105, and the bets played by the players are stored in the bet database 106 (which may be the same as the account database 105). The game organizer may start 20 and end games, set and change odds, and otherwise influence the operation of the entertaining application program via the operator interface 107.

·· #: Playing the game of chance using the software architecture shown in Figure 1 includes the following steps. The game organizer designs the rules of the game and the machines *: readable instructions to comply with the rules and stores them in the game database 103.

*: · *: 25 The game organizer also designs an interface screen that tells the player about the game and its rules and gives instructions on how to wager. This interface screen ····. ···. is saved as part of the user interface 102. After a player logs in, he or she follows the instructions and makes a bet. The log of player activity is stored in the account database 105, and the bet price is deducted from the player account. The bet itself is stored in the bet-30 socket 106. Based on the distribution of all bets stored on a particular game, the betting machine 101 repeatedly calculates the odds and updates them in the odds database 104. The outcome of the game is known either internally on the betting machine was a virtual process such as electronic raffle) or externally, whereby the game operator inputs it through the operator interface 107. The wagering machine 35 selects the winning bets, calculates their winnings and credits the bets. · 2 accounts of these players, which can spontaneously report results to players through the interface 102.

The disadvantage of such a prior art arrangement is its inflexibility. In principle, every game has to be designed and programmed from scratch. 5 The basic betting machine routines can be reused as long as the "new game" is nothing more than a new betting item, but this places strict limits on how games can be made. In particular, it would be difficult to provide fast, dynamically adaptable gaming capabilities with such a prior art arrangement.

It is an object of the present invention to provide a method and system for systematically designing and developing game applications. It is a further object of the invention to provide a method and system for creating and developing dynamically adaptable game applications. It is a further object of the invention to provide a method and system for dynamically changing the properties of a game application based on a player's unconscious input. It is a further object of the invention to provide a method and system that would enable simulation and verification of a systematically generated new game application in a realistic and / or futuristic environment.

The objects of the invention are achieved by executing an event model in real time so that it can represent a series of sub events in a target event, such as a football game of 20, car racing, or other interesting event that may include unpredictable smaller sub events. At the same time, a game model is executed that takes into account the development costs in the event model and looks for items that could form a game event. In addition, a player model representing the actions of one or more players may be executed in parallel, which may be taken into account depending on how the game events are played.

• · · • · · ·. ···. The method of the invention is characterized by what is disclosed in the characterizing part of the independent claim to the method.

The invention further relates to a system characterized by what is described in the characterizing part of the independent claim to the system.

The invention also relates to a method for creating an entertainment application program to be executed by means of player terminals characterized by: * ·, · which is disclosed in the independent claim to such a method. : in its logo section.

• · · • · 3

The invention also relates to a computer program product for providing entertaining application programs to be executed by player terminals, which is characterized in what is disclosed in the characterizing part of the independent claim on such computer program product.

According to a first aspect of the invention, we have a computer executable process that can be called an event model. It is a systematic representation of a series of sub-events that are likely to occur and together form a larger event that is likely to attract a large number of players. However, it is not known in advance exactly what 10 sub-events will occur and in what order in the larger event. The function of an event model can be easily understood by thinking of it as a state machine, although its actual implementation does not necessarily need to include one. In a state machine view, single input data from an event triggers transitions between different states in the event model. The actual event may be 15 real-world events such as a sporting event, an election, or any other event of public interest. Alternatively, the actual event may be partially or wholly virtual in nature, such as a computer game played by players online or a fully computer simulated series of events without direct human interaction. In the latter case, the implementation of the event model to-20 can even be integrated into a virtual event.

In another aspect of the invention, we have another computer executable process, which may be called a game model. Its function is to: '· *: run concurrently with the event model, observe what happens in the event model, and use its observations to decide what kind of games:. ·. 25 could be adapted to recent events in the event model. For example, if an event model moves to a state with a specific sub-event that has two or more • ·. well-defined possible outcomes are likely to occur in the near future, the game model may react by launching a game where players can • · ***** bet on all possible outcomes of the sub-event in that short 30 time period, when the actual outcome is not yet known.

• · · • · · ···. * ··. According to a third aspect of the invention, we still have a computer. an executable process that can be called a player template. Different tasks can be defined for the player model. According to one approach, one of the tasks of a player model is to predict how a typical player will react to a particular event in * * ·. Such a prediction can then be used, for example, to influence how games are offered to players. Proper application of the player model can help improve the emotional response of the game system to the players.

The event template, game template and player template can each have a routine library at their disposal. An event template can be any combination of event template routines that are stored in an event template library and customized to match a specific event. A game model can take advantage of a library of different game options, which it compares to events that occur in the event model. The player model can use a library of statistically described descriptions of how players are known to react to specific situations.

10 A coordinating body is required to link the models described above. This patent application designates such a coordinating body as an implementation technology machine. It can look like a space machine too, though other implementations are also possible. Typically, the implementation technology machine includes, for example, interface routines for coordinating the operation of many different devices and operating systems. It may also include monitoring routines to ensure smooth operation, for example, by preventing conflicts in which a fast-paced game would be mistakenly played on terminals that have too long a delay. Most preferably, the implementation technology machine has access to an implementation technology library that pre-stores previously created routines.

20 In order for the game organizer to control the operation of the system, it also preferably includes a control interface.

The new features considered to be characteristic of the invention are set forth in detail in the appended claims. However, the invention itself, its structure and function, and its further objects and advantages have been described in the following *: ··: 25 by way of some embodiments and with reference to the accompanying drawings.

The exemplary embodiments of this application are not to be construed as limiting the applicability of the appended claims. The term "encompasses" is used in this patent application as an open limitation which does not exclude features not mentioned herein. The features mentioned in the dependent claims can be freely combined, unless explicitly combined. ! ·. otherwise not mentioned.

• · · ··· ···

Figure 1 illustrates one of the state of the art entertaining application software solutions:. Figure 2 illustrates some concepts related to the invention, Figure 5 illustrates an exemplary gambling game section with connections, Figure 4 illustrates exemplary ways of obtaining inputs from a real-time event, Figure 5 illustrates an exemplary event model space machine, Figure 5 illustrates another exemplary event model space machine, Figure 8 shows another aspect of an exemplary game mode machine, Figure da illustrates another aspect of an exemplary player mode machine, Figure 9b illustrates another aspect of an exemplary game mode machine, 12 schematically illustrates the configuration of a game technology server. CONCEPTS AND NAMES 15 Some concepts and terms used in this specification are shown in Figure 2. Betting Game 201 is a multiplayer game that allows a large number of players to participate in the process whereby placing bets on the potential outcome of certain well-defined future sub-events can lead to profits. Said well-defined incoming alita-20 events occur in virtual event 202, semi-virtual event 203, and / or real-world event 204. Of these, virtual event 202 is a ♦ · ·: typically a process executed on a computer or computers in which simulated sub events occur in a virtual environment. A non-limiting example of a virtual event is a simulated car race where "cars" exist only in computational ··· »25 processes in computer memory and their progress on the“ track ”is controlled by virtual“ drivers ”, which are also computational processes. Semi-Virtual Level! * *. event 203 is a computer-driven process that is directly dependent on how a number of users • use their computer terminals: for example, virtual au. a race in which the "drivers" are computer users who give control commands and input in real-time through input devices such as keyboards, joysticks, or wheel-pedal combinations. A real-world event 204 is a typical: f, a sporting event, a music competition, an election, or some other real-world event that arouses public interest and is accompanied by arbitrary appearances ···. *. sub events (such as corner kicks in a football match) that can lead to a specific • · ♦ *; * j 35 to the final result (such as scoring).

• · · • · · • 6

The player sees the game interface 205 of game 206. Game 206 as such can be considered a sub-concept of the Veikka spit concept 201. It should be noted that the term "player" as used in this patent application refers to players participating in the bookmakers game, whereas persons whose movement and activity constitute the real world 5 sports event 204 (such as members of a football team) are referred to as "athletes". The generic term "third parties" in Figure 2 refers to the parties who influence the outcome of the event but do not participate in the betting game. Exemplary third parties, shown at the bottom of Figure 2, include: athletes, election candidates, and computer users who are not betting themselves, but 10 are just the drivers of a semi-virtual car race, for example.

The units shown in Figure 2 interact. Starting from the right, it is generally necessary that betting game 201 has no effect on the progress of real-world event 204; on the other hand, betting game 201 needs feeds from 211 real-world events, such as knowing that a goal was scored. Similarly, virtual event 202 and semi-virtual event 203 provide inputs 212 and 213 to the betting game 201 regarding the progress of the sub events: for example, what lap times of virtual cars or where and when a collision occurred. In the case of virtual and semi-virtual events, it may be acceptable to allow the betting game 201 to influence 214 or 215 events. In car racing, the relative numbers of players who have made 20 bets in advance may, for example, decide which country's course is selected for the competition, or players can vote on how much they can ... kea track should be.

*: · • · • ·: Continuous bidirectional information exchange for 216 player games and semi-virtual levels:: *; between event 203 is essential, at least when the player himself also participates in • · · · 25 semi-virtual events, such as driving a virtual car. Even if a player participates in a virtual event 202 as a "spectator" only, it is generally advantageous to provide a bidirectional data exchange 217 for transmitting real-time information from the virtual event to the player's terminal, and allowing the player to provide direct inputs such as encouragement. If only • · · '.Il 30 unidirectional data transfer is selected, this naturally means transferring information to the player's terminal.

When a player plays game 206, information about 218 of his actions is transmitted to the betting game player 201, which records it, for example, as a notification of the player's intention to bet. The return information from 219 betting games 201 to 206 games is mm. announcements of 35 new games, game-related information such as odds, and the results of settled sub-events and winnings of properly bets.

7

ACTION PLAY IN GENERAL

Figure 3 shows an advantageous construction of the betting game section 201. The following explains its components and the roles of the various components, as well as their interactions at a general level. A more detailed explanation of the key parts will follow later in this 5 text.

As an important part, the gambling game section 201 includes an event model 301, which is a real-time process designed to represent a series of sub-events occurring in a virtual, semi-virtual, or real-world event. In particular, the invention does not limit the resolution or granularity by which the development cost of an event 10 is modeled in the event model 301; this topic will be discussed in more detail below.

The gambling game section 201 also includes a game model 302. The function of the game model 302 is to monitor and respond appropriately to developments in event model 301. Since event model 301 is a machine executable representation of what actually happens in a given event, it can be said that game model 302 monitors the course of said event through the "filter" or systematic representation provided by event model 301. The advantage of this is that the game model 302 can use certain predefined systematic criteria to determine whether the event model 301 does something that could be the subject of the game.

... 20 The betting game section 201 also includes a player model 303 which is responsible for: 1 collecting and / or making predictions about player behavior. Player Model • · · 303 may provide tools for evaluating and / or adjusting the emotional response of a game to a player. This means that by exploiting information about how a player or players respond to a particular game presentation, schedule, or other feature, it is possible to optimize the formulation of games to maximize the enjoyment of the players experience. Although player model 303 merely collects data and does not actively generate predictions of player behavior or changes in the actual games, the data collected may later be used, for example, in accordance with their criteria • · ·. ···. to allow game model 202 to evaluate the suitability of certain game routines * "30 for certain situations in the event model. Including a player model * ·: · 1 in the betting game section 201 is not mandatory unless action binding to player behavior or information gathering is considered necessary. ·.: In bulk.

• · · • · · · · · · · · 8

The implementation technology machine 304 links the operation of Event Model 301, Game Model 302, and Player Model 303 to one another. The implementation technology machine 304 includes the necessary interfaces for arranging communication between different models. It is also responsible for organizing data transfer between the models and the outside world. to receive information from events, to send information to virtual and semi-virtual events, and to exchange information with players' terminals. Most preferably, the event model 301, the game model 302, and the player model 303 are all completely independent of any terminal or network technology, whereupon the implementation technology machine 304 is responsible for, for example, translating between the standardized communication protocols used in the gaming section 201 and the various communications

The control interface 305, which has bidirectional connections to all other parts of the betting game section 201, enables the game organizer to control the operation of the betting game section 201.

15 Event model 301, game model 302, player model 303 and implementation technology machine 304 are each linked to their own databases or libraries. These include Event Model Library 311, Game Template Library 312, Player Template Library 313, and Implementation Technique Library 314.

The use of libraries can be illustrated by the following non-limiting example 20. It can be assumed, purely as an example, that the event is a football match. In order to present the event, the betting game section 201 uses a state machine 301 as the event model, which proceeds from one state to another on the basis of feeds received from the actual event. It is impossible to know in advance how many i sub-events (such as corner and penalty kicks) will occur and when. Therefore, Event Model Library 311 has pre-existing partial routines that are not integral to Event Model 301 but that can be enabled as soon as a certain trigger condition is met. For example, when a penalty kick is announced, Event Model 301 reads from the Event Template Library 311 the relevant subroutine and begins to execute it, first switching to "ran-: ***: 30 gasp coming" where certain attributes indicate which team received • · · Penalty kick and why. When the penalty kick is kicked, the event pattern returns (via the "read result" function) to normal mode and sets up a partial routine for possible later use.

In the above example, information on the transition of the event model to a "penalty kick *: 35 coming" mode would be transmitted to game model 302, which would recognize this situation as a particular game. It examines Game Model Library 312 to obtain a partial routine for a quick betting game where players must guess the outcome of a penalty kick. Player Model 303 could respond to an upcoming penalty kick by checking the remaining game time after the event and reading 313 from the Player Model Library, which is the likely reaction of players to a penalty kick at this point in the football match. Knowledge of such predicted behavior could, for example, influence the odds given to potential outcome options in a fast betting game. Before publishing a quick betting game to players, the implementation technology machine 304 10 would review the expected response times of the various technology types 314 from the implementation technology library and allow only a fast betting game to be published for terminals without excessive delay.

Alternatively, it is of course possible to construct Event Model 301, Game Model 302, Player Model 303, and Implementation Technique Model 304 completely self-contained so that it-15 includes all possible subroutines for arranging a betting game for a particular type of event. In that case, the libraries 311, 312, 313 and 314 can be considered as a kind of design aid, from which the designer of such a self-contained gambling part will search for the subroutines needed to complete the models sufficiently.

20 To enable transactional communication and exchange of information with players' terminals, the implementation technology machine 304 has access to an '' *: an event interface 306 and a player interface 307. In its simplest form • ·,. ·. I get these are just communication links between the betting game section 201 and the event (event interface 306) and the betting game section 301 and the player's terminal (the player's · · · 25 interface 307). Some of the features that are considered part of the event interface. * 306 and player interface 307 may be physically located elsewhere. For example, ··· a player's terminal device, which in itself constitutes a so-called enabling technology, may include a Java-based virtual machine running on the actual user interface software that provides the player with an audio-visual interface 30 available to it. Some parts of such user interface software may originate from the betting game section 201 which then sends executable scripts to the players' terminal. ] ·. devices.

• · · · ♦ ·

O EVENT MODEL

• · • «· *; *; The implementation of the event model will now be explained in more detail. Observation * · ·: 35 An ascending, non-limiting example is the event model as a state machine in which transitions between states occur when certain events occur in the event being modeled. If an event is a virtual or semi-virtual event, it is relatively easy to derive information about any of its occurrences and pass it on to the event model, since it-5 cases only exist as computer executable processes that can be easily completed by data routines that always send data to the event model when something interesting happens in a virtual or semi-virtual event.

In the case of a real world event, it is a bit different and the tree of the 10 depends largely on the nature of that real world event. Figure 4 shows two exemplary options in the case where a real-world event is a sporting event. The most feasible option is to arrange an observer 401 to monitor the event and to input event descriptive data via the terminal 402. Such an arrangement is easy to implement and adaptable to many different events, but it also involves the possibility of human error. Figure 4 also shows how a sports field 403, athletes 404, and other important sporting event components 405 can be equipped with sensors 406 that automatically generate information about the sporting event. It is also possible to combine these two approaches so that information about the sporting event is generated and sent to the event model both automatically and manually. Manual monitoring and sensor based automatic monitoring ... principles can be easily generalized to other real-world events.

Figure 5 illustrates a simple space machine that can be used as an event model for a 25 lane sporting event. In the state machine representation of Fig. 5, the block having the rounded ends corresponds to the state, and the block having the coil I · * !. a nice recess at the end, corresponding to receiving information, and a block with a · · *** end projecting outward in the shape of an arrow point, corresponding to transmitting information. Vi-. a non-square block is not used in Figure 5, but would correspond to a decision • · · * ·] · * 30 actions that would have more than one end result, and a rectangular block would correspond to an operation whose results are internal to that state machine. The state machine is first in standby 501 when the match has not yet begun. »··. ···. 502 causes a transition to "match in progress" mode 503. The arrival of information from a known outcome of a 504 match can only mean that the match has ended.

*. *: 35 The state machine sends the known result in step 505 to, for example, a game model or to another process that needs it, which did not receive it when it became aware of the event model. Operation ends in "match ended" state 506.

Figure 6 shows a slightly more refined state machine for the same purpose. Waiting state 601 is similar to state 501 in Figure 5. Receiving match starting information 602 causes a transition to state 603 whereby the first half of the match is in progress. If in mode 603 information about the goal 604 is received, the updated match status is transmitted (e.g. to the game model) in step 605, then immediately returns to state 603. Another possible transition from state 603 occurs when information is received from the end of the first halftime in step 606. the state machine takes a pause in the wait state 608. The information about the start of the second half at step 609 causes the transition to "second half running" state 610. Steps 604 'and 605' are essentially the same as steps 604 and 605 above, with the only difference being that , returning from step 605 'to state 610 instead of state 15 603. The final whistle in step 611 causes the final result to be transmitted in step 612, after which the operation ends in "match ended" state 613.

Following the same pattern, it is possible to form arbitrarily complex space machines up to the point that every athlete, as well as the ball or puck or any other sporting element, is equipped with a sensor and all 20 movements are modeled and interpreted within the known rules of the game (e.g. does not indicate particularly advantageous even if he has · · ·: V left very close to the opponent's goal if he is at the same time offside. Another interesting feature of most state machine solutions is that they: can be implemented with a relatively small number of simple, standardized ·: ··· 25 components, such as - the beginning of a sub-event (timed or non-timed). - current status or position, or change (up or down) to a participant's or team's current position or position - advantage given to the participant or team (inning, free kick or similar) 30 - handicap or penalty imposed on the participant or team (penalty, handicap) or equivalent) • ·

* · "'- remaining time X

: - remaining distance or other physical measure X

: ***: - current value of speed, acceleration, weight or other physical quantity ···

X

• · · ** Ί 35 - End of the sub-event (based on time or result achieved).

• ♦ · • ·· • · 12

While the above list is sufficient for many purposes, it should not be considered exhaustive. These components may require parameterization, for example a standardized representation of a change in situation would include a small number of parameters such as who scored a goal or the like, at what point, who entered, how many points it received, what the situation was, etc.

There are markup languages, such as SDL (Specification and Description Language), to create an arrangement whereby a state machine designer selects and assembles standardized (graphically or character-rendered) components and then automatically retrieves and translates the corresponding source language pro-10 procedures or even machine-readable commands. executable program. The ice mapping automatically establishes communication interfaces between the different components, so that in describing the data transmission stage, it is only necessary to determine to which other stage or stages of the state machine description the data is to be transmitted. In addition, or alternatively (depending on the markup language), the description of the step of receiving the data must specify at which other step or steps the data is to be received. The auto-translator is then responsible for creating the actual read and write operations needed to transfer the data from the right source to the right destination (or from the right sources to the right destinations).

One preferred way to use the event template library is where the library is a passive collection of functionalities and rules for providing certain services. For example, the library contains snippets of code that an SDL compiler would use to create a machine-driven representation of a state machine built into a graphical user interface. The state machine is thus one way of arranging the execution of certain functions and rules read from the library for execution in the correct order. In some cases, the Event Template Library may contain alternate functionalities that are so close to each other! ···. could in principle be used to perform the function described in the state machine representation.

• ·

It is then advantageous if the translator asks the event model designer what action should be used in the machine-driven presentation.

30 Most preferably, the state machine or other process that forms the event model is sufficient. [·. independent so that it can be tested and verified, either against a simulation program or by entering a large amount of history data from known 1: · 1 events and verifying that the event model is performing correctly and delivering the correct results.

• · · • · · • ♦ · • · 13

It is also possible to run multiple event models representing the same event at the same time. For example, the event models shown as state machines in Figures 5 and 6 could be used simultaneously if, for example, there are different types of games offered to players, different types of player terminals, different network connections, different user interfaces for players, or other factors requiring different resolution or resolution.

GAME MODEL

Let us now look at certain aspects of the game model and its associated game library. At a relatively abstract level, the rules of the game can be divided into different categories, 10 of which are: - chance: winnings are given at random to a participant or participants over the entire rally - guess: a finite number of possible outcomes are known beforehand and winnings are distributed to participants based on 15 Outcomes - Exchanges: Participants exchange something, such as previously bets on sub-events that have not yet been resolved - Individual goal: Participant tries to perform as well as possible a task or set of tasks 20 - Winning condition: Participant wins if a certain criterion or condition is met, for example there are one thousand participants who do something.

·· · • · · •. ·. At a slightly more practical level, any one of these higher level gaming principles can be implemented with one or more practical implementation principles | such as: 25 - selecting the winner or winners by lottery or otherwise generating the correct result ··· ••• j regularly at certain fixed intervals - searching for the correct guesses or otherwise generating the correct result after a particular Glittering Underdog has occurred, and - updating the list of results or table after receipt of new information; and: ***: 30 providing the updated list or part thereof.

• · ·

As shown in Figure 7, the game model can use the time in standby 701 while waiting for ,,,,, "information about the event flow in one or more event models. · !: The 702 game model learns that the first condition is met; for example, one of the event models currently running at · · · j has moved to a state where the game can be organized in principle if the other condition is met. It is further assumed that it is typical of the first condition that it remains valid only for a known time. Thus, in step 703, the game model starts a time counter. In decision-making step 704, the game model repeatedly checks whether the time counter has run out. If the timer expires before the second condition is fulfilled, then returns to odo-5 state 701. However, before that, the game model learns that the second condition has been met, step 705, then moves to define the game according to certain predetermined rules, step 706. game implementation technology model, which then has the task of announcing the new game to the respective player terminals.

10 The conditions that must be met before announcing a new game may not have to be exactly two. There may be one, or significantly more than two. The time counter example described above should not be construed as limiting. Once a condition has been fulfilled, it may remain in the fulfilled state forever or until the game model receives the explicit knowledge that said condition is no longer fulfilled. The conditions may be interdependent, for example, if the first condition is met if the second condition is satisfied and the third condition is not, but not if the second and third conditions are both met, or if the first condition is fully satisfied if the second condition is false, but only partially if said second condition is simultaneously 20 true.

The invention is not limited to the selection or formulation of the terms. Taking the above example of a j-j * \: ball, one of a set of conditions could be: a football match is in progress (i.e. neither: "coming" nor "ended"), a free kick has been awarded but not yet given and a free kick awarded the selected athlete is a "sponsor" of the betting company especially sponsored by • · · · 25. Considering that many different types of events can be represented by different event models, pretty much any condition is acceptable as long as they define a situation where a large number of players have substantially the same chances to participate and win in a game that results and remains equally unknown to all players after which bets or other expressions of participation will no longer be accepted.

The game model may also react to information from other sources and sources other than simply stating that something has happened in a particular event model. In Figure 8, it is assumed that the game model in standby mode 701 (or indeed any mode) receives something indicative in step 801. For example, player model 35 may indicate that, according to its statistical observations, it has recently been created. and the game announced to the players attracted an extraordinary amount of interest in the stock, i.e.. attracted an exceptional number of players to participate. The game model may interpret positive announcement as indicating that said newly formed game was a successful operation, after which it modifies some of the criteria at step 802 in a manner likely to facilitate the development of similar games for play in the future. Otherwise, knowledge of a game that has only attracted relatively modest interest could dissuade the game model from developing similar games in the future.

PLAYER MODEL

10 Next, let's look at certain aspects of the player model. The purpose of the player model is to provide tools for observing, evaluating and possibly controlling the emotional response of games. The player model receives, or has received in the past, information about players' behavior in situations occurring during games. Under laboratory conditions, test subjects may be exposed to a variety of stimuli to observe how parameters that could be expressed and measured in a game situation reflect their feelings and reactions. Such parameters include e.g. observed mouse movement mode, observed mouse click speed and frequency, observed response time to various stimuli, and observed keyboard operation. In special cases, physiological measurements such as heart rate, eye movements or respiratory rate or blood adrenaline may also be used. Laboratory measurements can be used to derive universal reasoning rules, which can then be included in the: V player model.

'* 1' Figure 9a schematically illustrates the operation of a simple player model mode machine; In the learning phase, where statistics of players' reactions and / or measurements are collected for later use, state 901 is a standby state. In step 902, the player model receives new information about the observed player behavior. In step 903, uses the information obtained to update statistics describing the player's typical emotional responses to particular situations. Optionally!!.. · * In step 904, it may send some key statistics of the updated statistics to the other 30 processes that may need it, then return to standby 901.

• · · · · · · · · ·

During the game, the player model receives inputs from the user interface that indicate, for example: your most recent distribution of parameter values such as those mentioned above.

. ·. As a result, the player model provides standardized outputs for • • «35 other models that illustrate the conclusions the player model has drawn from the latest 16 observations regarding the emotional response of the game. The player model can also receive feeds from event and game models. For example, if a player model receives from an event model information about two or more related sub-events, it may use a database of previously formed laboratory measurements 5 to evaluate the emotional impact of such a combination of sub events: a equalized penalty kick with only five minutes remaining; players like a penalty kick in the first minutes of the match or when another team is already clearly leading the match.

Fig. Db schematically illustrates the operation of a simple player model mode machine in an "action step" where it dynamically responds to conditions and / or combinations of conditions observed in an event model or game model by generating player behavior estimates. In step 913, the player model converts said condition or combination of conditions to an estimated player behavior, for example, by searching for the best match between the current condition and a previously used test condition for which statistics of player behavior observed in a laboratory environment are recorded. technical tools can be used information about the player's most likely emotional reaction to the current circumstance or to a combination of 1 · · · ;; 1, the player model sends that information, for example, to the game model '·! ·' in step 914, followed by a return to standby 901.

It has already been mentioned how an indication of perceived player enthusiasm can be used to determine what kind and how many games will be released to players.

['··, There are other uses to the information created in the player template. With the permission of the player or players, the player model could, for example, control an individual player or a limited player. • · · *; | · 1 30 gambling addiction or compulsive gambling behavior. A positive indication could be * ···: used to anti-glare the system so that the system does not allow this. player: or players to play more than a certain amount. One option is to use a rating

• M

·· .1. the players' enthusiasm for setting odds or other rules of the game.

• · · · · · · · · · · 17 ·

IMPLEMENTATION ENGINEERING MODEL

Next, let's consider certain aspects of an implementation technology machine or model. Depending on the division of labor between the implementation technology model and other models, different embodiments may be presented. In a centralized solution, implementation technology model 5 is where the actual generation and storage of executable computer code takes place utilizing higher level definitions obtained from other models. A more decentralized solution would be to allow the event model, game model, and player model to form their own machine executable code and use the implementation technology template only as an entity to arrange communication between other models.

10 Regardless of the degree of centralization or decentralization, the implementation technology model is responsible for combining the features of other components and the requirements for the game and the entire gambling section into one functional entity. Components selected for a particular implementation must have sufficient capacity: for example, a computationally demanding routine can only be included in an implementation if it can be ensured that the available computing capacity is always sufficient to run said routine in all required situations. Security and confidentiality must also be taken into account: the implementation should include, for example, the necessary encryption and decryption routines to provide cryptographically secure communications when needed. The implementation technology model may also take into account cost considerations, for example by not allowing a particular implementation if it would entail excessive costs.

• · · • V The technology components available in the implementation technology model may include: mm: ···: - algorithms such as random number generators, encryption and decryption algorithms • · · · 25, and checksum calculators and hashers - procedures for determining coefficients for some predefined * criteria . • · - implementation of different game principles. - procedures for exchanging information with players' terminals, including establishing and maintaining connections (wireless, wired, dynamically changing); utilization of various telecommunications technologies (Digital Video Broadcasting (DVB), Global System for Mobile Telecommunication (GSM), General Packet Broadcasting (GPRS), Universal Mobile Telecommunications Services (UMTS), Wireless Local Area Networks (WLAN), Internet Service Providers (ISP)); and utilizing various data transfer protocols (Secure Sockets Layer (SSL), Hypertext

Transfer Protocol (HTTP), Traffic Control Protocol / Internet Protocol (TCP / IP) 18 - Security Procedures such as Terminal Authentication, User Authentication and Account Management - Database Procedures such as Centralized and / or Distributed Databases and Connections to External Databases 5 - Procedures for Creating User Interfaces utilizing various technologies such as, and, World Wide Web, Multimedia Home Platform (MHP), Short Message Service (SMS) or Multimedia Messaging Service (MMS).

Above all, the implementation technology model must include rules to ensure technical compatibility of all selected components and functionalities 10 and to organize their hierarchy and relationships. It must not allow implementations which present significant risks of technical failure or implementations which involve conflicting procedures. In addition, the implementation technology model may take into account the quality of the gaming experience experienced by players, such as reliability against interference and / or minimizing delays. If the successful gameplay of 15 games depends on responding quickly enough, the implementation technology model should not allow the game to be reported for playback on terminals that (or whose communication connections) carry a significant risk of excessive latency.

Fig. 10 is an operational and structural example of an implementation technology model. The advancement of the Tapah-20 nuclei is terminated by the state-of-the-art machine 1001, a computer-executable, state-to-state, programmed process that receives inputs and outputs according to a well-defined causal chain. It communicates with various subprocesses, four examples of which are shown in Figure 10, to perform operations that have some practical end-to-end results, for example, in establishing information or connections. To calculate the coefficients, *: · *: there is a coefficient calculation component 1011 coupled to the state of the art machine: 1001 through component interface 1012, which standardizes the communication between the component · · · · ·· * · and the state of the state machine 1001. • # · Why can be upgraded to the updated version without having to touch the interface. . ·. 30 engineering space machine side.

To create a user interface, another component 1021 exists, and a command line is provided. the component interface 1022 connects it again to the technology space machine 1001 and, if necessary. other components. Similarly, Figure 10 shows an example of an SSL connection \ component, 1031, which with component interfaces 1032 corresponds to a secure connection. *: 35 connections over an insecure network, and a TCP / IP connection component • · 1041, which is designed to implement TCP / IP-based connections. Also, 19 TCP / IP communication components 1041 have a component interface 1042. The simplest way to organize functional dependencies is a schematic representation of the state of technology machine 1001 as a direct user of all component processes. Alternatively, it is possible to arrange certain component processes to be in hierarchical relationship to each other, for example, so that the generic "connection maintenance" component manages the subcomponents designed to implement various alternate or complementary protocols, and the prior art need only communicate with the communications maintenance component.

SYSTEMATIC DEVELOPMENT OF NEW GAMES

10 Splitting a gambling concept into models such as an event model, game model, player model, and implementation technology model allows for the systematic development and synthesis of new gambling games, which can significantly speed up the process of moving from an idea to a realistic gambling game. Figure 11 schematically illustrates the development and synthesis process. In the beginning is idea 1101 about what the new betting game should look like. Typically, the next step is to develop the event model in step 1102 by utilizing information from the existing event model libraries in the event model library 311. In the next step 1102, a game model is developed, typically by adapting the existing game model routines of the game model library 312 to be associated with 20 suitable sub events that may occur in the event model.

In step 1104, a player model is developed that is bound to the event model and game model (or game models) associated with steps 1102 and 1103, again utilizing your knowledge of existing player model routines in the player template library 313: if possible. In step 1105, an implementation technology model is developed to bind the previously developed event model, game model, and player model. Assuming that the centralized solution mentioned above is used, the event template library 311, the game template library 312, and the player template library 313 contain more or less human-understandable rules and definitions for the subroutines in question. files or • · · * · ♦ · '30 corresponding computer executable commands are located in the implementation technology booklet * ♦ ·· * 314. In steps 1102, 1103, and 1104, most of the human-readable rules and definitions were worked on, but In 1105, the corresponding executable commands of the computer are retrieved and linked into a single entity, which ultimately forms a synthesized new batch in step 1106.

• ♦ ♦ • · · • ♦ 20

Any or all of the steps 1102, 1103, 1104, 1105, and 1106 may include verification, simulation, testing, and comparison of user experiences as graphically depicted in block 1111 in Figure 11. Although the flow of development appears to be a one-way path in Figure 11, this should not be construed as limiting; development work can also include load-oriented steps if, for example, during game development it is discovered that a slightly differently shaped event model would facilitate the adaptation of an existing game model routine for use in the new betting game.

VEIKKAUS GAME SERVER TECHNOLOGY

Figure 12 illustrates an exemplary server arrangement for implementing a betting game according to an embodiment of the invention. The server arrangement operating system environment includes means for executing state machines representing 1201 event models, game models, player models, and implementation technology models. It also includes means 1202 for performing core components of server arrangements, such as internal communication. It further includes means 1203 for performing server management, such as addressing and maintenance of memory 15, and means 1204 for performing other processes. Communication with other computer devices requires the implementation of various protocols, which are provided by means 1205 for executing communication-related components. To form interfaces toward human users (e.g., operators and players), the arrangement has means 1206 for performing components associated with the interfaces, and the actual interfaces 1207 and 1208. The libraries and space machines described above are not part of the server arrangement itself; it is assumed that the server arrangement is self-sufficient in that it is programmed with complete machine: V routines that may have been constructed using said libraries and whose operation may correspond to the progress of state machine representations.

• · · · · · · · · · · · · · · · · · · · · · · · · · · · · ··· · • ♦ · · · · ♦ ♦ ♦ ♦ ♦ ♦ ·

Claims (12)

A system for providing entertainment application programs to be executed via player terminals, the entertainment application programs having a gaming and / or gambling aspect, characterized in that: 5. The system comprises means for executing an event model (301), which is a process arranged to monitor and present sequences in the target event (202, 203, 204) in real time without affecting the occurrence of the sub-events in the target event, and - the system configured to provide an entertainment application program via player terminals in response to the event occurring in said event model (301); means for arranging said entertaining application program to receive from the player feeds describing the possible outcomes of the sub-events. A system according to claim 1, characterized in that said means for executing an event model (301) are arranged to cause the event model to proceed through a state sequence (501, 503, 506, 601, 603, 608, 610, 613) from said target event (301). 202, 203, 204) at a rate determined by the input data obtained (502, 504, 602, 604, 604 ', 606, 609, 611). A system according to claim 1, characterized in that it comprises means for executing a game model (302), which is a process arranged. respond to an incident in said event model by announcing the game to be made available to players' terminals. • · · • · · · The system of claim 1, characterized in that it provides means for executing a player model (303), which is a process arranged to describe the emotional response of at least one player to conditions occurring in the execution of an entertaining application program. . The system according to claim 1, characterized in that it provides means for executing an implementation technology model (304), which is a computer-preferred process including said event model. drivable oh- • ·. * ··. 30 in the form of a code. • · · • System according to claim 5, characterized in that said means for executing the implementation technology model (304) are further arranged to include a game model and a player model in the form of executable program code. System according to claim 1, characterized in that it comprises means for executing an implementation technology model (304) arranged to link an event model (301), a game model (302) and a player model (303), which themselves are in the form of executable program code. 8. A method for providing entertainment application programs to be executed via a wide variety of terminal devices having a gaming and / or gambling aspect associated with the entertainment application program, characterized by: - modeling a sub-event sequence belonging to the target event (202, 203, 204); ) 10, without prejudice to how the sub events occur in the target event, - providing execution of the entertaining application program via the players' terminals in response to an event occurring in said event model (301), and - receiving in said entertaining application program player feeds describing possible subtests. The method of claim 8, characterized by: - providing event information to the game model (302) of events occurring in said event model (301), and - responding to the event information in said game model (302) by notifying the game to players' terminals. : *. ·· 20 The method according to claim 9, characterized in that it: • · 11 • ·. . ·. - estimating the emotional response of at least one of the players to the conditions occurring in the execution of the entertainment application, - providing the estimated emotional response emotional response information to said game model (302), and - 25 - responding to the emotional response information in said game model (302); : ···: Criteria for announcing a game for players' terminals. 11. A method for synthesizing an entertainment application program to run Fri ···. via large terminals with entertainment applications featuring the gaming and / or gambling aspect, characterized by: .v 30 - modeling a target event (202, 203, 204) with an event model (301), which is a process that · · · is arranged to represent and follow a series of sub-events per. . ·. without affecting how sub-events occur in the target, ···, nucleus; • · · - verifying the operation of said event model (301) by simulating target event sub-events and feeding inputs from the simulated sub events to said event model (301); player feeds that illustrate the possible outcomes of the sub-events. 12. A computer program product comprising program code means stored on a computer readable medium for providing entertainment application programs via players' terminals when said program is executed on a computer which includes an gaming and / or gambling aspect of the entertainment software (1). ), which is a process arranged to display and track a series of sub-events in the target event (202, 203, 204) in real time without affecting the occurrence of the sub-events in the target event, and ), which the entertainment application program is configured to receive from the player feeds describing potential end-of-life events. results were published. • · · • • • • • · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · patent