IES83417Y1 - A multiple player interactive game - Google Patents

Description

Title A MULTIPLE PLAYER INTERACTIVE GAME Field of the Invention The present invention relates generally to the fields of telecommunications and gaming. More specifically, the invention relates to quiz games which are played via a telecommunications link.

Backgound to the Invention Telephone quiz games in which players connect to a server using a telephone and respond to one or more questions using keys on their telephones are well known in the art.

The functionality and appeal of the games is somewhat limited owing to the limited interaction available between one player and a computerised phone system.

Accordingly, there is a need for an improved telephone quiz game which provides greater appeal to potential participants.

Summary of the Invention Accordingly, a first aspect of the invention provides an interactive game system where multiple players may play the same game simultaneously, the game system comprising a communication means for communicating with two or more participants via a network connection, a question generation means for generating a series of questions for a game, a question forwarding means for communicating the first question in the series of questions in a game to the two or more participants via the communication means, wherein the question forwarding means is adapted to forward the next question in the series to each participant after the receipt of an answer for the previous question in the series from the participant, and an outcome determination means for determining at least one winner from the two or more participants at the end of the game.

In a preferred embodiment, the question forwarding means is adapted to simultaneously forward the first question in the series to participants.

Optionally, the game system may further include a delay means for creating a delay signal in response to a detected incorrect answer, wherein the question forwarding means is adapted to be responsive to the delay signal so as to delay the forwarding of a next question in a series until a predetermined period of time has elapsed.

In an optional embodiment, a reward calculation means may be provided for determining the total prize available to winners in a particular game. Preferably, the total prize is dependent on the number of participants in a game. Optionally, the number of prizes and the amount of each prize is determined by the number of participants in a game.

In a preferred embodiment, the game system further comprises a game registration means for receiving registrations requests from potential participants to log on to a game, the game registration means being adapted to determine whether the participants are eligible to log on to a game and accordingly grant permission. The determination of eligibility may be made with respect to the number of credits associated with the potential participant. The game registration means may be further adapted to only allow requests for a game within a predetermined time window.

Additionally, the game registration means may be adapted to limit the number of participants in a particular game.

The game registration means may be further adapted to send electronic invitations to potential participants at a predetermined time before the start of a game.

The communication means preferably comprises a computer server connected to the Internet. Preferably, the computer server is a WAP enabled server for processing and responding to requests from WAP devices.

In a preferred embodiment, the multiple player interactive game system provides a queuing method whereby players are placed in a queue to await commencement of a game.

This queue may be provided by sending each individual participants a queuing page. The queuing pages are set to automatically refresh alter a predetermined refresh period. The pages may include a timer value mdicating the time remaining to a game start. In a preferred embodiment, the system is adapted upon receipt of a request to refresh a queuing page to determine whether the queue is still operational, and if not to provide the participant with an alternative page. In the event that game has already started, the alternative page may be a missed game page, which informs the participant that they have missed the game. If the game start time is within a pre-defined amount of the current time, the alternative page is a game start page, in which the participant can commence the game.

In a preferred embodiment, the method of detection as to whether the queue is still operational comprises a two stage test. The first stage of the test comprises the at least one step of comparing the participants timer value with a predetermined minimum first stage timer limit, wherein the second stage is proceeded with where the participant’s timer is less than the predetermined minimum first stage timer limit. The second stage of the test may comprise the step of extracting an updated timer value from the database server and comparing this updated value to a predetermined minimum game time value to ascertain whether the queue is still operational. The first stage of the test may further comprise the step of checking the number of refreshes performed since a previous second stage test, wherein the second stage is proceeded with where the number of refreshes reaches a predetermined value. In the event that the first stage of the test is negative, then a refreshed page is presented to the participant. The timer of the refreshed page is decremented by a predetermined interval. The predetermined interval is preferably equal to the predetermined refresh period.

The second stage test may be performed initially when a participant joins the queue.

This queuing system is particularly advantageous for use with a WAP interface.

A second aspect of the invention provides a method of operating an interactive game where multiple players may play the same game simultaneously, the method comprising the generating of a series of questions for a game, the simultaneous communication of the first question in the series of questions in a game to the two or more participants simultaneously, forwarding the next question in the series to each participant after the receipt of an answer for the previous question in the series from the participant, and determining at least one winner from the two or more participants at the end of the game.

Optionally, the method may include the step of delaying the forwarding of a next question in a series until a predetermined period of time has elapsed, in response to the receipt of an incorrect answer.

The method may comprise the further step of receiving registrations requests fi'om potential participants to play a game, and determining whether the participants are eligible to play the game and accordingly grant permission to play the game. The determination of eligibility may be made with respect to the number of credits associated with the potential participant. The method may also include the restriction of only allowing requests for a game within a predetermined time window. Similarly the method may be adapted to limit the number of participants in a particular game.

In a preferred embodiment, the method further provides for the placing of players in a queue to await commencement of a game.

Brief Description of the Drawings The invention will now be described in greater detail with reference to accompanying figures in which: Figure 1 illustrates an exemplary block diagram of the overall structure of the system of the present invention, Figure 2 illustrates a more detailed block diagram of elements within the system of the present invention illustrated in Figure 1, Figure 3 illustrates a detailed block diagram of functional elements within the operating module of the present invention illustrated in Figure 2, Figure 4 is an exemplary flowchart of a method of playing a game using the system of Figure 1, and Figure 5 is a flowchart of a queuing process in accordance with the present invention.

Detailed Description of the Drawings The present invention will now be described with reference to an exemplary system implementation, a block diagram of which is shown in Figure 1.

The game system provides for the playing of a quiz game simultaneously by a plurality of game participants (l0,1l,l2,l3) over a suitable network. The system 1 of the present invention comprises a computer server 21 which is suitably adapted to connect with at least one associated database. The database may for example be accessed and operated using conventional database software, for example Microsoft SQL server. The game system comprises a communication means for communicating/interfacing with participants. This communication means includes a suitable interface device 20, for example a modem or network interface, which is provided to facilitate the connection of the system to one or more networks for the establishment of communications channels, for example by the Internet, in combination with one or more telephone networks, with the individual participants. The individual networks may be provided by traditional wire based land-line technology, wireless technology or a combination of both. A significant advantage of the present invention is that the individual participants may be located in different locations, i.e. there is no requirement for the participants to be co-located. The database may be housed on a separate server to the interface.

In addition to providing a physical communication e.g. by wire, wireless etc., the communications means also comprises a software interface which may be provided for example by WAP and/or Internet server software. This software interface allows participants to receive and View data extracted from the database of the present invention, for example using suitable browser software, e.g. NETSCAPE NAVIGATOR, MICROSOFT INTERNET EXPLORER, or through the WAP functionality provided in WAP enabled phones.

Additionally, the interface facilitates the adding or updating of information on the database. The software interface uses well know technology to provide participants with a series of pages for their viewing. A WAP site may for example be implemented using Microsoft ASP 3, whereas the Internet site may be implemented using ASP.NET.

In either case, data required from the database is extracted by an operating module which responds to requests fiom the Web/WAP interface. Techniques for generally implementing such interfaces are well known in the art and require no further explanation.

The database which may be implemented using conventional relational database techniques may be used to store three groupings of data. The first grouping of data is participant data 36. The participant data contains general information corresponding to the individual participants, for example their names, addresses, dates of birth and telephone numbers. Additionally, the participant data 36 may be used to store data relating to the status and performance of the individual participants, including for example the amount of credit remaining to play games, the date and time of their last game, their winnings etc. To store this data appropriately, the database is suitably provided with tables having fields for entering this data. For example, a table for storing participants may have a field for first name, last name, address etc..

A second grouping of data, question data 34, provides for the storage of questions and associated answers. These question are used in the actual games played by the participants. Preferably, the question data also contains an associated series of false answers for each question. The use of false answers means that contestant may be provided with multiple choice questions, in which they merely have to indicate the correct answer fiorn a list. It will be appreciated that multiple choice answers reduce the processing associated with a quiz game and overcome difficulties associated with incorrectly spelt answers etc.

In addition to questions and answers, the individual question data 34 may be stored against categories, with different categories identifying certain types of questions.

For example, the race questions can be general knowledge, sports (football, cricket, horse racing, formula one according to season and major events), gossip or other specific topics. In operation, when the questions relate to sport the game may be operated in such a way that participants progress in the game is identified by a location on a track, i.e. as fences in horse racing, corners in motor sport or hurdles in athletics.

Similarly, the individual question data may be classified by different degrees of difficulty. This may be used in determining a series of questions, with medium difficulty questions being placed at the start of a series of questions and increased difficulty questions being placed at the end of a series of questions.

The operating module 32, may be subdivided into a number of different elements which perform different fimctions, as illustrated exemplary in Figure 3, including for example, a participant registration module 50, a game registration module 52, a question generating module 54, a question forwarding module 56, a response detection module and an outcome detection module 60.

Although, these fimctions have been described as being performed modularly for the purposes of explanation, it will be appreciated the modules in software code may be individual fimctions, subroutines or even lines of code which may be interlinked and indistinguishable from other elements of code or modules.

The fimction of the participant registration module 50 is to register participants for the game, i.e. to provide an interface to contestants to allow them enter their personal details (individual participant data), for example their names, addresses, etc. Once this participant data has been entered, and optionally validated, the individual participant data is saved to the participant data section 36 of the database 22.

The function of the game registration module 52 is to enable potential participants to register for individual games. This is to be distinguished fiom the functionality provided by the participant registration module 50, which allows participants to register themselves with the system. In general, it is a prerequisite that the participants have registered themselves before they may register to play individual games.

The question generation module 54 is responsible for the selection and extraction of question data 34 from the database 22 for each game. The questions themselves are compiled and added to the question data section 34 of the database in advance of a game. Preferably, this task of question generation is completely automated.

The automation of the process minimises the overhead associated with operating the game and removes the possibility of operator tampering. The question generation module may extract the questions in a random fashion. Although the random extraction may be limited to classification or categories of difficulty depending on the game. For example, if the game was intended as a sports knowledge quiz, the question generation module may randomly extract questions classified as sport questions from the question data section 34 of the database 22.

The question forwarding module 5 6 is responsible for forwarding the questions to participants during a game. As individual participants will answer questions quicker or slower than other participants, it is important that the individual questions may be forwarded at separate times to the individual competitors. The question forwarding module ensures this.

As each contestant responds to questions, the response detection module 5 8 is responsible for detecting the answers supplied by contestants and determining whether the individual responses are correct.

The outcome detection module 60 has responsibility for determining who the eventual winner is at the end of an individual game.

The system of the game will now be explained in greater detail with reference to an exemplary mode of operation, as illustrated in Figure 4. The method commences with a participant connecting to the WAP/WEB interface of the system, for example by typing in the URL of the system into their browser sofiware. On connecting to the interface, the participants are presented 100 with a welcome (page) screen. The welcome screen typically provides basic information on the game. The welcome screen may provide for the selection of an option to allow potential participants to play/view a demonstration game. The welcome screen may also provide for the option of participant registration 105.

If a participant selects this option, the participant registration module 50 will be activated to allow the individual participants to register with the system to play the games for example by using an interactive WAP facility. In the WAP embodiment, the participants may use their mobile telephone number as a participant name. Similarly, the system may be adapted to automatically recognise participants from their telephone number and log them on to the system. Although, for security reasons, the system may also require the use of a password, which may for example be a simple participant selected or system allocated alpha—numeric password.

In another embodiment, participants may go through a more comprehensive registration process on an associated web site. This more comprehensive process may for example include the option of setting up account details into which automatic payment of any prize money awarded to a participant for being a winner in a game may be credited to their bank accounts. It will be appreciated that the provision of account details may not be required, for example where there is no prize money (fun games) or until the participant actually wishes to claim their prize money. Similarly, other methods for payment of prize money, for example by cheque may be allowed. By combining the registration process into two separate steps, one performed by WAP and one performed using an Internet browser, users are provided with the facility of playing using their WAP phones, but are not required to register themselves using WAP, which may be cumbersome and annoying for a user, because of the limitations of WAP browser devices.

In order for the game service of the present invention to be profitable, it is preferable that players pay to play games. This may achieved in several different ways, but one way to achieve this involves participants buying tokens to play games. To reduce costs and administration charges a useful mechanism known as "Reverse-billed SMS" may be used to facilitate the purchasing of tokens. This service which has been introduced by some telephone networks, including VODAPHONE and CELLNET in the UK allows for the billing of participants using switched messaging services (SMS) charges.

The process involves the sending of a SMS text message by would be participants which authorises a charge to be made to their mobile telephone bill for a service provided by the recipient (the operator of the game) of the text message.

This method of billing is particularly advantageous. In the present invention, on registering with the game service, potential participants are sent an invitation SMS asking them if they would like to buy a predetermined values worth (for example £1.50) of tokens to play the game. When would be participants reply to the SMS to the number of the game system operator, their reply is regarded as their authorisation for their mobile phone account to be billed an amount corresponding to the value of tokens offered. As soon as the system of the present invention receives the authorisation SMS it sends the consumer another invitation SMS so that they have it waiting in their message "Inbox" when they wish to purchase more tokens.

Alternative methods of payment may be provided including for example the use of purchased scratch cards (similar to those used for pre-paid mobile phones) or credit cards.

Once a participant has registered with the system, they may skip the initial participant registration process by proceeding directly with a participant login 110 from the welcome screen.

Optionally, once a participants has registered/logged in, they are presented with information telling them how many tokens/credits they have remaining. After which, they are presented with a main menu. The main menu gives details of games and enables participants to select games to take part in.

In a particularly advantageous arrangement, games (races) are advertised to start at particular times. There might be "big" races at, say, 0830 (commuter train time), 1330 (lunchtime) and 1830 (pub time). Although, “smaller” races may also be organised at fairly close intervals through the day. The frequency of games may be adjusted to find a balance between participants having a reasonably short wait for the next quiz, whilst ensuring that the wait is sufficient to allow enough participants to register and thus to generate a good prize.

To increase the attractiveness of the game, facilities may be provided to allow participants to play either "Public Games" which are the pre—scheduled versions described above and for which there may be no membership restrictions, or "Private Games" which individual participants may set up themselves. With respect to “Private Games” the system may be set-up to allow the organising participant to specify a start time for their game. The system may then generates a numeric code which when provided by a participant will allow that participant access to the “Private Game”.

To enhance the viability of these “Private Games”, functionality may be provided in the system to allow participants extend invitation to other participants, for example by building an "address book" of participants for each player, listing other participants they have competed against before. Thus when organising a game, the organising participant may select other participants known to them , e.g. by selecting from a list of participants with "check-box" functionality allowing them to select and SMS their invitees (this being charged back to the organiser of the game by SMS).

They could also add people to their address book manually.

Once a participant elects to participate in a game, they are presented 135 with a screen detailing the game and its associated rules. The participant may be provided with an option to withdraw at this stage. If the participant proceeds, the game registration module registers the participant to play the game and deducts 140 an appropriate token value from the balance of the participant.

The participants are then queued to await the commencement of the game. This queuing process will now be described in greater detail, with reference to the exemplary flowchart of Figure 5.

Unlike existing game formats, it is a general requirement of the game of the present invention that participants playing the same game should start more or less at the same time. However, it would be extremely difficult to get participants to register their participation at just the right time (simultaneously) to start a game. Accordingly, the present invention provides for a queuing process, which may for example be provided by the operating module. The queuing process places registered participants for a game in a queue to await commencement of the game.

As the present system is preferably implemented using a browser interface, either WAP or HTTP, the queue may be provided for each individual participant as a queuing page (either WML or HTML), i.e. the participants will see a page on their screen indicating that they are queued for the start of a game. The queuing pages may be as simple as to provide a text message stating “The Game begins shortly”. The individual queuing pages may include a timer value indicating the time remaining to a game start. In this case, the message provided may be “The game will commence in X minutes and Y seconds”. To ensure that the participantwis not left with the same message indefinitely, the pages are set to update themselves after a predetermined refresh period (for example every four seconds). For example, this may be provided using the refresh command in HTML or the timer command in WML. Thus if the predetermined refresh period was four seconds, then the participant browsers would attempt to refresh (reload) the queuing pages roughly every four seconds.

The purpose of the queuing process is to allow participants to register for a game within a given period before the start of the game, for example anywhere between a few seconds and a few minutes, whilst at the same time ensuring that they start the game more or less simultaneously with other participants.

Shortly before each game commences, participants should be removed from the queue and placed in the game, i.e. instead of receiving a queuing page they should receive a game start page.

As there may be several computers providing the web/W AP interface connected to a single database server, it is preferable for this and other reasons that the database server acts as a reference timer for the whole system. It is this timer that determines when a game starts.

However, if a check of the server timer was performed at each refresh of a queuing page, the computational/server overheads would be significant. To overcome this problem, the system of the present invention provides a two stage test to determine whether a queuing page is still required (i.e. whether the queue is still operational). The first stage of this test 235,240,245 is a crude test which uses the individual participant’s timer values and/or other data to determine whether a more accurate second stage test ,215,225 is required, in which a check 205 is made of the server’s timer.

For example, the first stage of the test, may comprise the step of comparing 240 the individual participant’s timer value with a predetermined minimum first stage timer limit (for example 20 seconds). In the event that the second stage of the test is not required, the queuing page may be refreshed with a new queuing page in which the individual participant’s timer value has been updated. This updating 235 may be performed by decrementing the previous timer value of the participant by a fixed amount. In the example shown, the updating 235 is performed prior to the first stage 240/245 of the test. It will be appreciated however that this merely changes the value used to perform the check. The fixed amount used to decrement the timer is preferably equal to or calculated from the predetermined refresh period (i.e. four seconds).

In the event that timer is less than required amount, e.g. 20 seconds, the system proceeds with the second stage of the test. The second stage of the test extracts an updated (extracted) timer value from the system 1 itself (preferably from the database server of the system). This extracted timer value is compared 225 with a game start value (in the present example four seconds) to determine whether the queue remains operational, i.e. has the game started or is it about to start. In the event that the queue remains operational, the queuing page may be refreshed 230 with a new queuing page in which the individual participant’s timer value has been updated. In particular, the individual participant’s timer value is updated with the updated (extracted) timer value from the system. This two stage test reduces the amount of processing for the database SCTVCI.

In the event that the queue is determined as no longer being operational, the participant is presented with an alternative page 210/220 to the queuing page. In the event that a determination 215 is made that the game has already started, the alternative page may be a missed game page 210, which informs the participant that they have missed the game. Alternatively, the alternative page provided to the participant is a game start page 220.

The advantage of the above described two stage test is that a reduction in the processing overhead is achieved as calls to the database are relatively "expensive" in terms of processing power and operational overhead, whilst at the same time mis-starts are avoided because close to the game the participants timers are synchronised.

A disadvantage of the method is that the timer the participant is presented with is not always completely accurate. As WAP connections are notoriously slow - a couple of seconds could elapse between refreshes, meaning that 6 seconds may pass rather than the 4 seconds that the system presumes.

To overcome this problem, the present invention may provide a second test within the first stage of the two stage test, the second test comprising the step of checking 245 the number of refreshes performed since a previous second stage test. In the event that a second stagetest has not been performed for a predetermine number of refreshes then the second stage of the test is performed. This in effect ensures that the individual participant’s timers are re-synchronised regularly, which ensures that the participants timer’s are not wildly inaccurate.

To initialise a participants timer, a second stage test may be performed initially when a participant joins the queue.

This queuing method is particularly suitable for use with a WAP interface, where the time for refreshing may be unreliable or irregular.

The queuing process will now be explained in greater detail with reference to an exemplary mode of operation. When a player first joins a race queue, the operating module queries the database to fetch the latest information about the race that the player is registered for. This latest information may for example, include the time until the race starts and the number of players currently queuing.

Although, the number of players registered for any particular game is stored on the database, it is extremely inefficient to retrieve this value from the database each time it is required. Accordingly, the number of players in the queue is used to update a global variable held locally by the operating module that is available to all members of the queue. Other data, for example the player name, etc., is stored in a private memory space which is accessible only to the individual player. l 6 The number of players is stored in a public variable as it is applicable to all players - and hence it will always remain accurate as when players join/leave the public variable will be updated, and hence all players will see the newly modified number.

The operating module may perform an initial check to ensure that the race has not already started. This may be achieved, for example, by checking that the time remaining to the game start is not less than zero or by detection of an appropriately set flag. In the event that the race has already started, the participant may be directed to try and join another game on an appropriate WAP/web page.

The operating module may then check to determine whether the race is about to start or not. This may achieved, for example, by checking whether the time remaining to the game start is less than a pre-determined amount (for example 4 seconds) or by detection of an appropriately set flag. In the event that the race is about to start, the player is directed to start racing, for example by presenting them with a new WAP/web page corresponding to the game.

In the event that the race has not yet started and is not about to start, then the player is shown a web/W AP page detailing the estimated time until the race starts. The number of players that are currently in the queue may also be displayed. After a given refresh time, for example 4 seconds, the page attempts to refresh. This refresh may be implemented using well know techniques in the art, for example the refresh command in HTNIL.

However, instead of performing the steps of interrogating the database previously described again, the operating module decreases the player’s timer by 4 seconds (corresponding roughly to the time spent on the previous page).

The operating module then checks if the timer is less than a predetermined level (for example 20 seconds) and/or whether the counter is equal to a certain number (for example 4). If neither of these is true then the system redirects the participant back to the queue page, if either is true then the system fetches the latest data from the database and the process repeats.

The advantage that this system has over one that calls the database with every refresh is that although the web server is "hit" with every refresh of the queue page, the database itself is only called every 1 in 4 refreshes. This reduces the processing overhead as calls to the database are relatively "expensive" in terms of processing power and operational overhead.

Afier the queuing process the game commences with the individual players being presented 150 with their first question more or less simultaneously.

The individual players may respond to the questions be providing an answer 155.

After the first question, it is unlikely that participants will receive the questions simultaneously as the participants will take different times to answer the questions. The response detection module 58 of the present invention detects 160 whether the answer provided is correct or not and optionally may maintain a total of the number of questions answered correctly.

In terms of game rules and methods of operation, a number of different formats are possible. In a first exemplary format, participants attempt to answer a series of questions comprising a fixed number (for example 10) of questions, with individual participants being delayed 165 by a predetermined period (c. g. two seconds) for each wrong answer they supply. The delay may be implemented by providing the participant with a delay screen 170 informing them they got the answer wrong. In this exemplary format, the first participant to "finish" is the winner, irrespective of how many wrong answers they get. In other words someone who is quick can get an answer wrong can beat someone who has answered all questions correctly, but slowly.

An alternative format requires players to answer as many questions as possible in a given period of time, e. g. 90 seconds. The winner is the quickest of those who have answered the most correct questions.

In either case, as each question is answered, a check 175 is performed to determine whether the game is still in progress, i.e. whether there is any time and/or questions remaining. In the event there is the next question in the series is presented .

Once the game is completed, the participants may be presented 185 with a screen asking them to wait while scores are tabulated, after which the individual participants are notified as to whether they have won or lost.

Prizes may be awarded to enhance the attractiveness of the game. In order to ensure that prizes are fair and provide an adequate return to the promoter of the service, a prize formula may be used. According to one exemplary method of calculation prizes may be based upon a geometric progression. In this geometric progression, each player receives half the prize of the player above him, the total payout being equal to the sum of all the payouts. As shown below: prize, prize, + prize, + priZ€,,,,,,e,,_1 T l: ' .. ota przze1+ 2 2 2 , l : P}-lZel X2X{1— ) To calculate the 1“ prize the formula is reversed: Total 2><[1— 1 J Zplayers This is then used to calculate the prize for each player, dependant on their position: prize, = prlzeposition = prlzel X 2 position Additionally, the present invention may be enhanced to include facilities to run leagues. These leagues may be broken down by standard and/or by location.

Conceivably, the game structure could be such that as participants move up the league structure they may unlock higher levels with harder games and potentially higher prizes.

Although, the present invention has been described with reference to an exemplary embodiment, It will be readily appreciated by those skilled in the art that modifications may be made without departing from the spirit and scope of the invention which is intended only to be limited by the accompanying claims. For example, the exemplary embodiment described herein may readily be modified to accomodate the playing of the game using wireless 3G technology.

The words “comprises/comprising” and the words “having/including” when used. herein with reference to the present invention are used to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.

Claims (1)

1. An interactive game system for the playing of a quiz game by multiple players simultaneously, the game system comprising: a communication means for communicating with two or more participants via a network connection, a question generation means for generating a series of questions for a game, a question forwarding means for communicating the first question in the series of questions in a game to the two or more participants via the communication means, wherein the question forwarding means is adapted to forward the next question in the series to each participant after the receipt of an answer for the previous question in the series from the participant, and i an outcome determination means for determining at least one winner from the two or more participants at the end of the game. . A game system according to claim 1, further comprising a delay means for creating a delay signal in response to a detected incorrect answer, wherein the question forwarding means is adapted to be responsive to the delay signal so as to delay the forwarding of a next question in a series until a predetermined period of time has elapsed. . A. game system according to claim 1 or claim 2, wherein the system is adapted to place players in a queue to await commencement of a game. . A game system substantially as hereinbefore described with reference to and/or as illustrated in the accompanying drawings. . A computer implemented method of operating a game substantially as hereinbefore described with reference to and/or as illustrated in the accompanying drawings. TOMKINS & C0.