US20100035673A1

US20100035673A1 - Options trading game

Info

Publication number: US20100035673A1
Application number: US12/497,920
Authority: US
Inventors: Daniel Kertcher; Matthieu Stone
Original assignee: PLATINUM PURSUITS GROUP Pty Ltd
Current assignee: TRADING PURSUITS Pty Ltd
Priority date: 2004-10-19
Filing date: 2009-07-06
Publication date: 2010-02-11

Abstract

A gaming server for a gaming system is disclosed. The gaming server is operable to implement a multi-player options trading game. The gaming server comprises a data retrieval module arranged to retrieve historical trading data for at least one asset, the trading data relating to a plurality of consecutive trading days. A processing module is also implemented by the server which, prior to commencement of game play, is arranged to process the retrieved historical data for each asset to determine incremental trading information for at least one trading period within and for each of the plurality of consecutive trading days, the incremental trading information utilisable by players to determine whether to place an order in the game. The gaming system also comprises a player terminal interface module which during game play is arranged to: (a) retrieve and facilitate display on a player terminal display, predetermined incremental trading information associated with a first period in time for an asset selected by the player; (b) receive inputs from the players to place orders for call or put options based on the incremental trading information within a specified move period, the specified move period being shorter in length than the incremental trading period; and (c) upon expiration of the specified move period, present each player, via the player terminal display, with updated incremental trading information for the selected asset, the updated incremental trading information associated with a subsequent trading period derived from the historical data. Finally, a determination module of the gaming server determines the performance of each player and causes steps (a) to (c) to be repeated until a performance criterion has been met.

Description

This application is a Continuation-in-Part of U.S. Ser. No. 11/252,412, filed 17 Oct. 2005, which claims benefit of Serial No. 2004906047, filed 19 Oct. 2004 in Australia and which applications are incorporated herein by reference. To the extent appropriate, a claim of priority is made to each of the above disclosed applications.

TECHNICAL FIELD

This invention relates to an educational options trading game.

BACKGROUND TO THE INVENTION

It has been tried to provide options trading games. However, to date the prior art options trading games have been primarily intended for amusement purposes only and do not accurately reflect real life trading. For this reason, they do not serve as useful educational aids to options trading. Furthermore, prior art online options trading games that offer multi-player game play are not capable of effectively scaling to accommodate for many players.

SUMMARY OF THE INVENTION

In a first aspect the present invention provides a gaming server for a gaming system operable to implement a multi-player options trading game, the gaming server comprising:
a data retrieval module arranged to retrieve historical trading data for at least one asset, the trading data relating to a plurality of consecutive trading days;
a processing module which, prior to commencement of game play, is arranged to process the retrieved historical data for each asset to determine incremental trading information for at least one trading period within and for each of the plurality of consecutive trading days, the incremental trading information utilisable by players to determine whether to place an order in the game;
player terminal interface module which during game play is arranged to:

- (a) retrieve and facilitate display on a player terminal display, predetermined incremental trading information associated with a first period in time for an asset selected by the player;
- (b) receive inputs from the players to place orders for call or put options based on the incremental trading information within a specified move period, the specified move period being shorter in length than the incremental trading period;
- (c) upon expiration of the specified move period, present each player, via the player terminal display, with updated incremental trading information for the selected asset, the updated incremental trading information associated with a subsequent trading period derived from the historical data; and

determination module arranged to determine the performance of each player and cause steps (a) to (c) to be repeated until a performance criterion has been met.
In an embodiment the historical data comprises open, close, high and low price for each asset.
In an embodiment the historical data further comprises data representative of in-between price movements during each trading day.
In an embodiment the incremental trading data comprises a closing price for the previous period and an asset trend indicator.
In an embodiment the asset trend indicator comprises at least one of the following indicators: implied volatility, Delta, Theta, Vega, Rho, 0-200 day simple & exponential moving averages, 0-200 day standard deviations and bid and ask prices for each selected asset.
In an embodiment a randomised element is introduced into the data for multi-player game play.
In an embodiment the specified time period for each move is selected by one of a game administrator or player(s) prior to game play.
In an embodiment the time period for each segment of incremental trading information comprises one of a full day, half day, hourly, 30 minutes, 15 minutes, 10 minutes and five minutes.
In an embodiment the time period for each segment is selected by one of a game administrator or agreed upon by one or more of the players prior to game play.
In an embodiment the processing module further comprises an executable game module, the executable game module arranged to issue files that are executable by each player's terminal for carrying out the steps performed by the player interface terminal.
In an embodiment the files are issued responsive to determining a resource utilisation indicator of the server is critical.
In an embodiment the resource utilisation indicator comprises one or more of the following: CPU, RAM, disk space, and data retrieval speeds for the server.
In an embodiment the performance criterion specifies that a player has achieved either the highest rate of return or highest percentage rate of return by the end of the game period.
In an embodiment the performance criterion specifies that a player has executed one or more predetermined options trading strategies within a specified time period.
In accordance with a second aspect the present invention provides a gaming system comprising a gaming server in accordance with the first aspect arranged to communicate with at least one player terminal operable participating in a multi-player options trading game implemented by the gaming server.
In accordance with a third aspect the present invention provides a tangible computer readable medium storing a computer program comprising instructions for controlling a computer to implement the gaming system in accordance with the second aspect.
In accordance with a fourth aspect the present invention provides a method of carrying out an options trading game including the steps of:
a) presenting the players with a real life example of historical trading information for a particular stock, the trading information relating to a first point in time;
b) allowing the players to make orders for call or put options based on the historical trading information; and
c) presenting the players with updated trading information; the updated trading information relating to a subsequent point in time and allowing assessment of the trading performance of each player.
The trading information may be presented as a chart.
The method may further include the step of repeating steps b) and c) until a pre-determined criteria is met.
The predetermined criteria may include that a player has made a certain amount of profit or loss.
The predetermined criteria may include that a pre-determined number of repetitions have been made.
The method may further include providing player tokens and a game board and the player tokens are moved in relation to the board based on trading performance of the players.
In a fifth aspect the present invention provides an apparatus for playing an options trading game including:
a) means for presenting the players with a real life example of historical trading information for a particular stock, the trading information relating to a first point in time;
b) means for allowing the players to make orders for call or put options based on the historical trading information; and
c) means for presenting the players with updated trading information; the updated trading information relating to a subsequent point in time and allowing assessment of the trading performance of each player.
The means for presenting may be provided in the form of a display screen.
The trading information may be stored in an electronic format.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

FIG. 1 depicts a game board of an embodiment of the present invention; and

FIG. 2 depicts a calculation sheet used in an embodiment of the present invention;

FIG. 3 depicts a trading diary sheet used in an embodiment of the present invention;

FIGS. 4, 5 and 6 depict historical trade charts used in an embodiment of the present invention;

FIG. 7 is a schematic of a gaming system arranged to carry out multi player game play over a communications network;

FIG. 8 is a block diagram of the functional components of the gaming server illustrated in FIG. 7;

FIG. 9 is a flow diagram illustrating method steps in accordance with an embodiment of the present invention; and

FIGS. 10 a and 10 b are screen shots of a player interface, in accordance with embodiments of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Embodiments of the present invention relate to a methodology, apparatus and system for providing an options trading game based on historical “real life” trading data.

Board Based Implementation

The trading options game of this embodiment includes the following materials:

1. A game board
2. 1-6 Player pieces
3. A pack of trade cards. Each trade card identifying a particular stock.
4. A DVD including historical trade charts for the stocks identified in the trade cards.
5. A trading diary pad
6. A calculations pad
7. An educational DVD explaining the mechanics of options trading and also explaining how to play the game.

Aim

The aim of the game is to be the first player to turn their starting capital into $1,000,000.

Set Up

Each player is assigned $10,000 starting capital and a player piece. Each player puts their piece at the point marked “START” on the game board of FIG. 1. The trade cards are shuffled and placed in a stack face down at the point marked “TRADE CARDS” on the game board of FIG. 1. The DVD is inserted into a DVD player and connected to a presentation means in the form of a television display or computer display.

Play of Board Game

Play commences by one player drawing the top card from the pile of trade cards and reading out which stock is identified on the trade card. Each stock is also identified by a number which corresponds to an index of the DVD. The DVD is accessed at the point identified by the number on the trade card to present a real life example of historical trading information in the form of a stock chart. The players are then allowed to decide whether they wish to trade a call option or a put option. Once they have made their decision, they perform their money management calculations on the calculations sheet of FIG. 2 and then submit their orders on their trading sheet of FIG. 3.
Once all players have completed trading, the DVD is then advanced to present the next real life trading chart. The next chart relates to the day of trading subsequent to the day of the chart previously presented to the players. The players can determine from this chart their trading performance in terms of profit and loss. The players then make further trading decisions relating to their existing holdings, and decide whether to hold, sell or buy more options. The chart is then advanced another day.
Play continues until the trade comes to a close (usually after 10 or 20 charts). Once the trade is finished, players assess their final scores. If they have made a profit, then they move their game piece forward on the board to the approximate amount of their total capital. For example, if they have started with $10,000 and have now made a $2,000 profit, their total capital would be $12,000. Therefore, they now move their playing piece forward to the $12,000 mark.
If they have made a loss, then they move their playing piece backwards on the board. For example, if they have started with $10,000 and made a loss of $3,300, then they now have a total capital base of $6,700. Therefore, they would move their piece to the $6,000 mark, being the closest amount to their actual capital. The dollar amounts on the board represent their total capital.
A new trade card is then drawn and the play continues as above until a player is at the point on the board “$1,000,000”.
Players have a quick reference sheet available to them to review option trading techniques.
Every trade example included in the game is of an actual stock, and all stock prices are accurate. FIGS. 4, 5 & 6 depict historical trade charts from three consecutive days of trading being 11^th, 12^thand 13^thFebruary respectively. It can be seen how the stock and options prices and the chart changes from day to day.
The option prices shown in the charts are accurate, but are approximate “snap shot” prices from the day's trading. By way of explanation, actual open, high, low, and closing stock prices are recorded each day for a real life stock. In the real world, option prices are constantly changing during the day on a second to second basis. The option prices presented in the game are an average of the option prices from that day. By using real life trading charts, if a player trades well in the game, they could have traded well in real life trading. In other words, basing game play on real life historical trading data provides players with an accurate and educational aid to options trading which cannot be achieved using randomised data.
The game includes a 2 hour training DVD, teaching players about the US options market, trading tactics, and strategy, thus making the game suitable for beginner and experienced option traders.
The game allows players to experience the emotions of trading and thus gain a great deal of option trading experience in a very short time period and at no financial risk.

Computer Implemented Embodiment

An alternative embodiment of the present invention will now be described with reference to FIG. 7. According to the illustrated embodiment, the game is implemented by a gaming system 70 arranged to facilitate both an individual and multiplayer historically based options trading game play. A plurality of player terminals 72 communicate with a gaming server 74 of the gaming system over a communications network 76 in the form of a packet-switched network such as the Internet. As will be described in more detail in subsequent paragraphs, the gaming server 74 operates to perform a range of pre-game calculations on the historical trading data that ensures scalability, thereby allowing the gaming system to provide massively multi-player functionality if required.
According to the embodiments described herein, the gaming system is in the form of a thin client-type system whereby the gaming server 74 controls most of the game and the player terminals 72 essentially provide only the player interface displayed by the terminal display (e.g. by way of a browser application or the like). A player interface of the game controller 80 receives player order instructions, passes these to a processing module 82 of the gaming server 74 for processing and then returns game play outcomes for the player terminal to display. The player terminals 72 may, for example, be computer terminals, e.g. PCs running software that provides a player interface operable using standard computer input and output components (it will be understood that the player terminals may alternatively comprise portable electronic devices running appropriate software for communicating with the server, such as mobile phones, PDAs, etc.).
Persons skilled in the art will appreciate that in accordance with known techniques, functionality at the server side of the gaming system 70 may be distributed over a plurality of different computers. For example, elements may be run as a single “engine” on one server or a separate server may be provided. For example, the gaming server 74 could run a random generator engine. Alternatively, a separate random number generator server could be provided. Further, persons skilled in the art will appreciate that a plurality of gaming servers could be provided to run different games or a single game server may run a plurality of different games as required by the terminals.
Persons skilled in the art will also appreciate that the method of the preferred embodiment could be embodied in program code. The program code could be supplied in a number of ways, for example on a computer readable medium, such as a disc or a memory (for example, that could replace part of memory 103) or as a data signal (for example, by downloading it from a server).
In more detail, and with additional reference to FIG. 8, the gaming server 74 implements a game controller 80. For simplicity, only those modules needed to carry out embodiments of the invention are illustrated in FIG. 8. Other standard and/or non-standard modules may also be implemented e.g. for carrying out operation of non multi-player game play functionality.
The game controller 80 includes a processor 82 which is arranged to carry out the pre-game calculations based on historical trading data relating to a plurality of consecutive trading days and generally control play of each game. It will be apparent that the processor 82 implements a number of modules, namely a random number generator module 821, historical data retrieval module 822, processing module 824, player terminal interface module 826, determination module 828, display controller module 830 and executable game module 832, based on program code stored in memory 84. A trading period store 842 is also implemented in memory 84 for storing the algorithms and other data required to generate pre-game historical trading period data, as will be described in more detail in subsequent paragraphs. Persons skilled in the art will appreciate that not all modules need be implemented by processor 82. Other implementations are envisaged. For example, the functional modules of FIG. 8 may be implemented in hardware of separate units, or a combination of hardware and software as separate units. Any practical implementation of these functional units may be employed.
In more detail, the data retrieval module 822 is arranged to retrieve historical data relating to a plurality of consecutive trading days for at least one asset of one or more specified asset class (e.g. equity, bond, foreign exchange, commodity markets etc). In an embodiment the historical data comprises the following information for each asset per day: open price, close price, high and low prices and information relevant to each asset class such as earnings per share. Preferably the retrieval module 822 is arranged to retrieve data for a large number of different assets for each class to replicate the real-world environment. In an embodiment the retrieval module 822 is arranged to interface (e.g. over the Internet) with a stock exchange 78 or other historical data provider, to retrieve the historical trading data. According to such an embodiment, the historical data may be retrieved each day, or in batches. Alternatively, the historical data may be loaded onto the system using a tangible media, such as a hard disk, which stores the historical data and downloaded by the server 74. As will be appreciated, the plurality of consecutive trading days may be relatively current (e.g. pertaining to the last weeks worth of trading data) or may be old data (e.g. dating back tens of years), depending on the desired game play and/or rules set by an administrator, or agreed on by a group of players participating in a particular game. The retrieved data is stored in a historical trading information database 851, in association with each asset.
Prior to commencement of game play, the processing module 824 retrieves the historical trading information from the historical trading information database 851 and processes the data in accordance with the processing rules stored in memory 841. In an embodiment this step involves dividing each trading day's data for each asset into specified periods. The periods may be specified by a game administrator or agreed on by a player or group of players participating in a particular game. A series of algorithms are then applied to each trading period's data to generate incremental trading data which can be utilised by players in determining whether to place an order for an asset. In an embodiment, the trading data includes close data representative of a closing price of the last period and at least one trend indicator which allows the player to see how the asset is trending (which should assist in helping them place an order). As will be described in more detail below, the trend indicator(s) are determined by applying various algorithms (also stored in memory 841) to the data and include calculation of implied volatility, Delta, Theta, Vega, Rho, 0-200 day simple & exponential moving averages, 0-200 day standard deviations and bid and ask prices for each equity, currency, commodity, bond underlying and option strike prices for the standard future option periods. An explanation of these indicators can be found at the following Internet URL, the contents of which are incorporated herein by reference: [http://en.wikipedia.org/wiki/Greeks_(finance)]. The results of these calculations are stored in the database 852 and used as an information source for players to asset price and generate indictors during game play. The calculations are stored for game moves (or turns).
A game moves consists of at least a portion of a trading day's worth of historical data (i.e. an incremental time period) played out within a time period (hereafter “move time”) which again may be specified by either the game administrator or player/group of players participating in the game. For example, the incremental time period may be a five minute chunk of the trading day played out in a five second move time. It will be understood that the move time could be shorter or longer, however in all embodiments will be less than the actual time period of the incremental data to facilitate game play that is faster than real time. The advantage of having a variable move time is that players of a high standard may, for example, elect a relatively short move time whereas beginners may opt for a longer move time to allow them more time to analyse the asset information and determine an appropriate strategy.
In an embodiment, the ingested historical data may consist only of a day's starting price and a day's ending price. In such an embodiment, random data (generated with the aid of the random number generator 821) may be used to generate the in-between price movements. As will be appreciated, each change in underlying asset price requires its own generation of the above calculations.

Game Setup and Administration

The game controller 80 implements a player terminal interface 826. The interface 826 may provide an administration interface for game operators to define a new game based upon the historical data. As mentioned above, games may consist of trading one or more assets; from a single stock to a multiple assets across the equities, commodities, currencies, and bond markets (i.e. a portfolio of assets may be traded at the same time). It will be appreciated that tournament games can be 100% historical data based, 100% randomized data based, or any mix in between. Preferably, for educational embodiments, the game play will comprise of %100 historical based data, however to avoid cheating in tournament style games, a randomised element may be mixed into the data to prevent cheating. For example, a random offset could be applied to the historical data (e.g. the close price) at various times to slightly vary the actual historical data. Individual games can begin at any time, whereas tournament games are required to begin at a specific time. In an embodiment, the game administrator may also insert multimedia events such as audio, text, video and flash objects that will be triggered in the game client at certain points throughout the game. Through an administration Game Administrator constructs tournaments based upon a collection of games.
The game controller 80 may define recommended trade points at different points in the game. These can be assigned manually or via an algorithm. The trade points are assigned according to different trading strategies. These are used in educational games and during game client playback to help players better identify trading signals.
The game controller 80 also defines the rules for a player to join the game. These are open to all, having achieved a certain game level, or having a cost to join. The cost can be real or virtual currency. The game controller 80 defines rules of the specific game. These rules include the game timeframe and whether the game is played on a single asset, a collection of assets, or all assets.
The determination module 828 of the game controller 80 interfaces with the player interface module 826 to determine winning outcomes based on determination rules stored in memory 842. The rules may, for example, specify that a player with the highest rate of return or highest percentage rate of return by the end of the game period is the winner. Alternatively the winning criteria may be that a player must have executed one or more predetermined options trading strategies within a specified time period (e.g. by the end of game play). Other winning criteria are envisaged and should not be seen as being limited to those criteria defined herein. It will be understood that game winners can be single, hierarchical, or multiple. Furthermore, it will be understood that the game controller 80 may define defines game prizes as one of a mix of no prize, achieving a game level, virtual game currency, or a cash prize.
In an embodiment the game controller is arranged to construct a group of educational games. Each educational game (which may be single or multiplayer) is designed to demonstrate how trading strategies perform across a range of trading environments. Completing the educational games unlocks indicators that can be used to execute specific trading strategies: e.g. Bollinger bands and 2 standard deviation indicators.
Processes Requests from Player Terminals
The game controller 80 receives two types of game requests from player terminals, via the player terminal interface, namely: for individual games or tournament (i.e. multiplayer) games. For each game type, the game controller 80 receives requests to start a game and request other players join. Other players can be specific individuals or individuals who are online at that time. The request can be to start a game immediately, or at a future time and date.
The player interface module 826 of the game controller 80 coordinates the responses from the individuals and begins the game at the allotted time. At the game beginning the processing module 824 performs account balance adjustments, based upon the cost of entering the tournament if required.
The game controller 80 runs the games as per the game rules stored in memory, subtracting and adding the players balance based upon their game transactions. Should a game player achieve a negative balance, and then unless they have a credit arrangement, they will receive a “Game Over” message and will only be able to watch the game from that point on.
At the end of the game, based upon the game rules, the determination module 828 updates the client records and leader boards (stored in memory as client data 843 and leader board data 844), before returning a message, with the aid of the display controller module, to be displayed on the relevant game terminals user interface with an updated balance, whether the client is a winner or loser and if any relevant prizes. The relative positions of the other players on the leader board may also be displayed on the user interface.

Massive Multi-Player Online Game Functionality

In an embodiment, in addition to the pre-game historical data calculations, the game controller 80 is arranged to create separate executable game processes that can be played out on the respective player terminals 72 (using suitable hardware and/or software). These “spawned” games advantageously allow the system to scale to a massive multi-player online game supporting millions of concurrent player terminal requests as will be described in more detail below.
When new historical data is obtained, the game controller 80 performs a range of calculations across the data. The resultant data is stored alongside the historical data enabling quick retrieval during game play. Thus when a game requires this data, it can be returned with one database lookup without requiring any CPU intensive calculations.
Individual games are created by the executable game module 832 of the game controller 80, as a separate executables with data and business logic, returning the results to the game controller 80 either when complete, or as the game is progressing. Individual games can quickly be assembled from pre-existing game logic and data.
To prevent fraud, each spawned game is signed with a one-time use certificate (also created by the executable module 832). As a game is created from business logic and data, a one-time use certificate is also included. Only requests from a valid certificate will be responded to. Once the game is complete, the one-time use certificate has been consumed; the game will cease to communicate with the gaming server after receiving acknowledgement from the executable game module 832.

Online Example of an Embodiment

An example method 900 of playing an embodiment of the game of the invention will now be described with reference to the flow diagram of FIG. 9 and FIG. 10 screen shots. This example shows the game controller operable to carry out game play for a two person multiplayer tournament game using the foreign exchange options as an asset class. The game consists of five days worth of trading data (i.e. a typical week). The days are split into five minute intervals (i.e. the interval period is five minutes), taking five seconds of game play (i.e. move time is five seconds). The market data consists of a mix of 70% historical and 30% randomly generated data. Again, this randomised element may be achieved by applying a randomised offset to either the pre-processed historical data or to the processed incremental data. The tolerance or range of the randomised offset may, for example, may be set by the administrator or the like to control the randomisation of the market data. The winner is the player who has either generated the most amount of profit by the end of the game, or the player who has incurred the smallest loss (i.e. as defined by the game rules stored in memory).
At step 902, prior to commencement of game play, the data retrieval module 822 retrieve data relating to five days worth of historical or “real life” information for 5 different foreign exchange options. The processing module 824 then processes the data as previously described into five minute chunks of incremental trading data.
At step 904, both players individually log into the game website maintained by the game server 74 from separate player terminal browsers and elect to play a foreign exchange options tournament game against each other. They are both presented with a screen similar to that shown in FIG. 10 a and the game begins at the same time for each player (step 906).
The game controller 80 decides whether to the players are able to play the game, based upon rules setup by the game administrator. The executable module 832, based on resource utilization, decides whether to spawn a new process to handle the game moves (step 908).
In more detail step 908 involves the processing module of the game controller determining whether the server has enough resources available to handle massive amounts of game client requests. It constantly monitors its resource utilisation indicators (e.g. CPU, RAM, Disk Space, & Data Retrieval speeds). If these indicators exceed predetermined thresholds, the executable module 832 will spawn off new game requests into separate processes. These processes are run both on separate game controller hardware, and/or on shared or “cloud infrastructures” provided by a third party such as Amazon. Game clients will then communicate with the new game process, with the game process only communicating balance changes and transaction data for each move, and the end of game details to the game controller 80.
If one game is serving thousands of clients, it can be spawned into one master game process with many child processes, each of these child processes can run in existing game controller hardware or on infrastructure provided by a third party service such as Amazon.
In the event of a game process being unable to contact the game controller, the game process will retry until a time-out period has expired, in which case it will alert the game clients that an un-correctable error has occurred and the game results will be declared null and void. If the game process has completed the game, it will continue trying until the game controller becomes available. If the event of the game controller losing contact with a game client or game process, it will retry until a time-out period has expired, then declare the game results null and void and roll back any related transactions. If the game controller experiences a failure, when it is restarted it will search for games in an unknown state, attempt to contact respective game clients or game processes. If contact can be re-established, then it will validate the state, then continue as normal. If contact cannot be re-established, then it will declare the game results null and void and roll back any relevant transactions.
Using their player terminal interface, the players are able to request historical data for a current time period for a particular asset (step 910). With reference to FIG. 10 a, the data is in part provided on a graph and allows the player to see and draw various indicators, see the current market price of the underlying asset, see the bid and ask prices of each option strike price for both put and call options.
As the players watch the market move and prices of both the underlying asset and the options change, they are able to place their orders according to their trading strategy, using the interface (912). After each move the processing module 824 adjusts their respective account balances etc. based on their performance (914). Players can ensure a specific trading strategy is carried out by utilising the trade window shown in FIG. 10 b. Players are able to place their orders with associated stop and profit levels and have the game auto-trade for them. Depending upon the game rules, the game controller may or may not display an updated game leader board.
If the game controller has been programmed to display multi-media events or educational content during the course of the game, then these will be triggered in the player interface module at the same time for both players according to their associated timeline.
Advantageously, for each move, the game controller 80 is not required to perform any processing (other than perform balance adjustments) since the incremental data (e.g. the underlying asset price, put and call option strike prices, and associated trend indicators including Delta, Rho, Theta and Vega, plus a range of Standard Deviations, Fibonacci numbers, simple and other moving averages) for each move have been calculated prior to commencement of game play. In other words, calculations occur only as data is obtained (e.g. downloaded); once initially for the historical data, then once a day as the previous days trading data is obtained.
At the end of the game (916), the player terminal interface 826 communicates the ending positions for each player to determination module 828. The determination module 828 then returns notification to the interface of whether the players are winners or losers. Winners will receive the prize as determined by the determination module 828. Players will have the ability to replay the game with any associated trade points being highlighted, and be able to play any associated educational media associated with the game.
Any reference to prior art contained herein is not to be taken as an admission that the information is common general knowledge, unless otherwise indicated.
Finally, it is to be appreciated that various alterations or additions may be made to the parts previously described without departing from the spirit or ambit of the present invention.

Claims

1. A gaming server for a gaming system operable to implement a multi-player options trading game, the gaming server comprising:

a data retrieval module arranged to retrieve historical trading data for at least one asset, the trading data relating to a plurality of consecutive trading days;

a processing module which, prior to commencement of game play, is arranged to process the retrieved historical data for each asset to determine incremental trading information for at least one trading period within and for each of the plurality of consecutive trading days, the incremental trading information utilisable by players to determine whether to place an order in the game;

player terminal interface module which during game play is arranged to:

(a) retrieve and facilitate display on a player terminal display, predetermined incremental trading information associated with a first period in time for an asset selected by the player;

(b) receive inputs from the players to place orders for call or put options based on the incremental trading information within a specified move period, the specified move period being shorter in length than the incremental trading period;

(c) upon expiration of the specified move period, present each player, via the player terminal display, with updated incremental trading information for the selected asset, the updated incremental trading information associated with a subsequent trading period derived from the historical data; and

determination module arranged to determine the performance of each player and cause steps (a) to (c) to be repeated until a performance criterion has been met.

2. A gaming server in accordance with claim 1, wherein the historical data comprises open, close, high and low price for each asset.

3. A gaming server in accordance with claim 2, wherein the historical data further comprises data representative of in-between price movements during each trading day.

4. A gaming server in accordance with claim 1, wherein the incremental trading data comprises a closing price for the previous period and an asset trend indicator.

5. A gaming server in accordance with claim 4, wherein the asset trend indicator comprises at least one of the following indicators: implied volatility, Delta, Theta, Vega, Rho, 0-200 day simple & exponential moving averages, 0-200 day standard deviations and bid and ask prices for each selected asset.

6. A gaming server in accordance with claim 5, wherein a randomised element is introduced into the data for multi-player game play.

7. A gaming server in accordance with claim 1, wherein the specified time period for each move is selected by one of a game administrator or player(s) prior to game play.

8. A gaming server in accordance with claim 1, wherein the time period for each segment of incremental trading information comprises one of a full day, half day, hourly, 30 minutes, 15 minutes, 10 minutes and five minutes.

9. A gaming server in accordance with claim 8, wherein the time period for each segment is selected by one of a game administrator or agreed upon by one or more of the players prior to game play.

10. A gaming server in accordance with claim 1, the processing module further comprising an executable game module, the executable game module arranged to issue files that are executable by each player's terminal for carrying out the steps performed by the player interface terminal.

11. A gaming server in accordance with claim 10, wherein the files are issued responsive to determining a resource utilisation indicator of the server is critical.

12. A gaming server in accordance with claim 11, wherein the resource utilisation indicator comprises one or more of the following: CPU, RAM, disk space, and data retrieval speeds for the server.

13. A gaming server in accordance with claim 1, wherein the performance criterion specifies that a player has achieved either the highest rate of return or highest percentage rate of return by the end of the game period.

14. A gaming server in accordance with claim 1, wherein the performance criterion specifies that a player has executed one or more predetermined options trading strategies within a specified time period.

15. A gaming system comprising a gaming server in accordance with claim 1 arranged to communicate with at least one player terminal operable participating in a multi-player options trading game implemented by the gaming server.

16. A tangible computer readable medium storing a computer program comprising instructions for controlling a computer to implement the gaming system in accordance with claim 15.