METHOD FOR IMPLEMENTING A COMPUTER GAME

Abstract

A method of displaying scores of players in a game tournament played on connected computing devices, each with an integral display, in which one or more processors cause the scores for each player for a specific round of the game to be recorded and then causes the scores for that specific round to be displayed in a scoreboard that includes at least one linear bar divided into two sections, the length of each section being determined by the processor to indicate the relative scores of each player.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based on, and claims priority to U.S. Provisional Application No. 61/701,907, filed Sep. 17, 2012; UK Application No. 1302121.7, filed Feb. 6, 2013; UK Application No. 1302910.3, filed Feb. 19, 2013; UK Application No. 1304442.5, filed Mar. 12, 2013; UK Application No. 1304444.1, filed Mar. 12, 2013; UK Application No. 1304545.5, filed Mar. 13, 2013; UK Application No. 1306117.1, filed Apr. 4, 2013; UK Application No. 1306118.9, filed Apr. 4, 2013; U.S. Provisional Application No. 61/811,019, filed Apr. 11, 2013; U.S. Provisional Application No. 61/818,702, filed May 2, 2013; U.S. Provisional Application No. 61/827,298, filed May 24, 2013; U.S. Provisional Application No. 61/832,348, filed Jun. 7, 2013; U.S. Provisional Application No. 61/832,355, filed Jun. 7, 2013; U.S. Provisional Application No. 61/832,359, filed Jun. 7, 2013; U.S. Provisional Application No. 61/832,362, filed Jun. 7, 2013; U.S. Provisional Application No. 61/832,364, filed Jun. 7, 2013; U.S. Provisional Application No. 61/832,369, filed Jun. 7, 2013; UK Application No. 1310589.5, filed Jun. 13, 2013; UK Application No. 1310592.9, filed Jun. 13, 2013; UK Application No. 1311119.0, filed Jun. 21, 2013; UK Application No. 1314147.8, filed Aug. 7, 2013; and UK Application No. 1316045.2, filed Sep. 10, 2013, the entire contents of each of which being fully incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to casual social games.

2. Technical Background

There are multiple technical challenges facing the designer of computer-implemented games to create a fun and compelling game. Three of these challenges can be broadly categorised into the following areas: ‘engagement’; ‘viralisation’ and ‘monetisation’.

We will look first at ‘engagement’, which involves designing gameplay to be engaging and rewarding to players. This typically requires games to be easily understood at their simplest or introductory levels, providing rewarding gameplay with quite simple game mechanics, but becoming progressively more challenging so that players are not bored, but remain engaged and develop rewarding skills Effective engagement requires various forms of feedback to reinforce players' sense of success and accomplishment. Effective engagement can be greatly magnified if the game has as social aspect—for example if it is linked to a social network so that game players can interact with their friends in the social network. The game can then transform into something that goes far beyond a solo game experience and become more like a shared journey.

‘Viralisation’ requires a game to include various techniques that encourage players to share the game with others, encouraging them to play the game. It is a key technique in enabling mass-scale distribution or penetration of games. Viralisation can be especially effective when the game is integrated into or connected to a social network environment in some manner, so that the game can then propagate through the network of player's friends, and their friends and so on.

‘Monetisation’ covers those techniques that enable revenue to be generated from a game; this involves many challenges, because the monetisation techniques need to be acceptable to players and in no way undermine engagement.

A successful and original game will require a team of game designers to solve complex problems of engagement, viralisation and monetisation; this can take many months of skilled work and, not infrequently, a great deal of trial-and-error testing of new ideas, functions and game mechanics before a game successfully combines all these elements into a new experience.

A ‘match-3 game’ is a type of casual puzzle game where the player is required to find patterns on a seemingly chaotic board. The player then has to match three or more of the same type of game element on the game board and those matched elements will then disappear.

One variant of casual games are the so called ‘clicker’ games where the player can click on a group of adjacent game elements of a certain type and those will then be removed. Some clicker games only require two adjacent objects to remove those elements if clicked by the user.

Another type of match-3 games are the so called ‘switcher’ games where the player switches place on two adjacent game elements on the game board so that one or both of them create a chain of at least three adjacent game elements of the same type. Those matched game elements will then disappear. In a typical switcher game the game board will be repopulated with game objects from the top of the board with the physics of the game board being that the game pieces are falling downwards on the board.

Another type of match-3 game are the so called ‘shooter’ games where the player launches for instance a ball or bubble on to the game board tying to aim at groups of similar game elements already on the game board. If the launched ball hits or forms a group of more than 3 similar game elements then that group of game elements are removed fro the game board. In a typical shooter game the physics of the game board being that the game pieces are falling downwards on the board.

There are also other types of games where groups of certain game elements are combined together and removed when they have reached a certain size. The user can connect the groups with a swiping movement touching each of the connecting elements in one implementation and in another implementation the groups are formed to one group when the elements of the same type are adjacent, the player then removes the group for instance by clicking on that group.

This patent specification describes not only various ideas and functions, but also their creative expression. A portion of the disclosure of this patent document therefore contains material to which a claim for copyright is made and notice is hereby given: Copyright King.com Limited 2012 and 2013 (pursuant to 17 U.S.C. 401). A claim to copyright protection is made to all screen shots, icons, look and feel and all other protectable expression associated with the games illustrated and described in this patent specification.

The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but reserves all other copyright rights whatsoever. No express or implied license under any copyright whatsoever is therefore granted.

3. Discussion of Related Art

Casual social games have been implemented before and are known. However previous inventions have not successfully devised effective solutions to one or more of engagement, viralisation and monetisation in the same way as the present invention does.

SUMMARY OF THE INVENTION

A first aspect is:

A method of displaying scores of players in a game tournament played on connected computing devices, each with an integral display, in which one or more processors cause the scores for each player for a specific round of the game to be recorded and then causes the scores for that specific round to be displayed in a scoreboard that includes at least one linear bar divided into two sections, the length of each section being determined by the processor to indicate the relative scores of each player.

Any one or more of the following optional features may be included, resulting in a method:

• • in which a processor causes the sections to be in different colours.
  • in which the game is a two player tournament and there are two sections, one for each player, and the longer section is coloured differently from the shorter section.
  • in which the longer section is brightly coloured compared to the shorter section.
  • in which there are X rounds for each tournament and hence X linear bars, each indicating the relative scores for each player in each of the X rounds.
  • in which there are three rounds for each tournament and hence three linear bars, each indicating the relative scores for each player in one of the three rounds.
  • in which the linear bar for a specific round of the tournament does not indicate the relative scores for either player until both players have finished that round.
  • in which the display shows a button that, if selected by a player, initiates a signal to be sent that causes the or a processor to display a screen that includes multiple available boosters or charms available to a player.
  • which the display shows multiple available boosters or charms, and the player is permitted to use one booster or charm for free.
  • in which the display shows multiple available boosters or charms, and the player has to pay for them using an in-game currency, and that in-game currency is topped up automatically to a pre-defined level at pre-defined time intervals.
  • in which the pre-defined time interval is 30 minutes.
  • in which the display shows multiple available boosters or charms, and the player can select a booster or charm by dragging and dropping it onto a target area.
  • in which the target area includes outlines corresponding to each possible booster or charm that can be dropped into the target area.
  • in which the display shows a second option or button that, if selected by a player, cause a signal to be sent to a processor to commence game play.
  • in which the display shows a button, such as a ‘rematch button, that, if selected by a player, causes a signal to be sent that initiates another game play tournament between the players.
  • in which each section also displays the numeric score achieved by one player superimposed over a section of the linear bar associated with that player.
  • in which the display is a touch screen display.
  • in which the game is an asynchronous social game
  • in which a processor is located at a remote server.
  • in which the computing device is a portable, personal wireless device, such as a smartphone or tablet.

A second aspect is:

A computing device adapted to play a computer game, the device including a processor, a memory, a display, a touch screen or a cursor based input device, and computer code stored in device memory or on a remote server and executable by the device processor or a remote processor, and in which the computer code generates computer game graphics for the display on the device;

• • in which a processor causes the scores for each player for a specific round of the game to be recorded and then causes the scores for that specific round to be displayed in a scoreboard that includes at least one linear bar divided into two sections, the length of each section being determined by the processor to indicate the relative scores of each player.

A third aspect is:

A non-transitory computer readable medium encoded with instructions for controlling a computer system to display a game on a display; and in which the instructions running on the processor(s) result in:

• • the scores for each player for a specific round of the game being recorded and then causes the scores for that specific round to be displayed in a scoreboard that includes at least one linear bar divided into two sections, the length of each section being determined by the processor to indicate the relative scores of each player.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a schematic illustration of a computing device.

FIG. 2 portrays an exemplary overall environment in which the present invention can be utilized.

FIG. 3 shows account creation and login process.

FIG. 4 shows an illustration of the progression through a whole game of three rounds where the players have to be on the same rounds in order to play.

FIG. 5 shows an illustration of a strictly turn based implementation when playing against another player.

FIG. 6 shows an example of what the final result view may look like.

FIG. 7 shows an alternative implementation of the result screen.

FIG. 8 shows an alternative implementation of the result screen.

FIG. 9 shows an example of what the main view may look like.

FIG. 10 shows an example of various options on how to find other users to play against.

FIG. 11 shows one implementation of what it could look like if wanting to start a rematch with a friend.

FIG. 12 shows one implementation if what it could look like when finding friends from a social network to play against.

FIG. 13 shows an example of one implementation where the player can search for friends.

FIG. 14 shows an example of one implementation where a player has received an invitation by another player.

FIG. 15 shows an example of what the information may look like when it's the player's turn to continue on the current round in a game session.

FIG. 16 shows one implementation when it's the opponent's turn to play the current round.

FIG. 17 shows one implementation of what it may look like when an opponent has yet not been found.

FIG. 18 shows one implementation of what the choose-booster-view may look like together with a drag and drop function.

FIG. 19 shows one implementation of a score meter.

FIG. 20 shows an alternative implementation of a score meter.

FIG. 21 shows a simplified overview of what a game iteration may look like.

FIG. 22 shows an exemplary implementation where one group of two game elements of the same kind is highlighted.

FIG. 23 shows one implementation of a match-3 switcher game.

FIG. 24 shows an alternative implementation of a match-3 shooter game.

FIG. 25 shows an exemplary implementation where some game blocks have been removed.

FIG. 26 shows an exemplary implementation where a beam hovers above game blocks for a short period of time before falling down and destroying game blocks.

FIG. 27 shows an exemplary implementation where bomb blocks are randomly placed in the play field.

FIG. 28 shows an exemplary implementation of the detonation area when a bomb block has been clicked.

FIG. 29 shows an exemplary implementation of when game blocks have fallen down after the detonation of a bomb block.

FIG. 30 shows one implementation where the characters supporting the beam can fall off if the beam is only supported with one block.

DETAILED DESCRIPTION

The terms user and player are used interchangeably throughout this document and no specific meaning is intended using one or the other unless the context suggests otherwise.

In the following description of various implementations of the invention, reference is made to the accompanying drawings which form a part thereof, and in which is shown by way of illustration various implementations in which the invention may be utilized. It is to be understood that other implementations may be utilized, and structural and functional modifications may be made without departing from the scope of the present invention.

FIG. 1 shows a schematic picture of a computing device, containing a Central Processing Unit and Random Access Memory. The CPU acts according to input given from input devices, such as a keyboard, mouse or touchscreen. Computer BUSes are used to communicate, both between input devices and the CPU, but also between different controllers within the computer device, such as the graphics controller and the network controller. These controllers in turn communicate with external devices, such as a monitor for video output with which the graphics controller communicates, and the network controller communicates with for instance the internet, through wireless or wired connections. A user can interact with the computing device through input devices, such as a pointing device (e.g. a mouse) and a keyboard.

FIG. 2 portrays an exemplary overall environment in which the present invention can be utilized. A virtual game is stored on for instance a game server 210. The virtual game is to be played on a client device, such as a computer 240, 250 or a smartphone or other handheld device 260. The client device can also be a kiosk, arcade gaming station, smart TV or other device with computing capabilities, input devices and a screen that can present the game to a user. The client device communicates with a game server 210 and a social network server 230, for instance through the Internet 220 or other network. It should be understood that the social network 230 and the game server 210 does not have to be located in different places, they could be on the same server or on a plurality of servers located in different locations. An environment where the invention may be implemented is described in PCT/EP2013/060641 which is hereby incorporated by reference. People skilled in the art will understand that other devices than the exemplary ones listed can be also be used without departing from the spirit and scope of the invention.

Different Implementations

The techniques described in this patent can be deployed in many different gameplay architectures. For example, a computer game can be implemented as a computer program that is stored and runs entirely locally on the processor of a PC, games console, tablet or mobile telephone or other computing device. The game can be implemented solely as a computer program that is stored and runs entirely on one of many processors in a remote server, and data streams or updates are supplied to the client device (e.g. tablet, smartphone etc.) to enable the client to render and display graphics and sounds; this ‘web services’ approach is increasingly common.

Another approach is a hybrid one, in which back-end servers handle some elements of the gameplay, and for instance a Java game applet is provided to client devices and it is the locally running Java applet that generates the graphics/sounds/user interaction for gameplay on the player's client device. Some data may be fed back to the back-end servers to enable scoring, interaction with other players and cross-platform synchronisation. Generally, the techniques described in this specification are not specific to any one game architecture but can be deployed on any suitable game architecture.

The game can be implemented allowing a user to interact with it in different ways depending on the capabilities of the device which the user is accessing the game with. A user can interact with the game through using a touch screen where the user can select and/or move elements on the game board with a finger or for instance with a stylus. The game can also be played with a pointing device such as a mouse or other interaction devices such as a keyboard.

Mobile devices may have a touch screen interface where the player can interact with the game using a finger or a pointing device such as a stylus. Some mobile devices have hard keys that complement the touch screen interface. Such hard keys may be in the form of a button or in the form of a joystick type of interaction.

Over the course of players playing the game, data will be produced. This data can for instance be related to a player's game performance or to game information related to a social network to which the game is connected. It is possible to gather this data, store it and make use of it for instance to improve the game. One example is by using a database to store the amount of times players try and fail a level or a certain level layout on average. This data can then be reviewed, and if the players seem to fail a substantial amount of times before completing a level, the difficulty can be adjusted accordingly. The difficulty can be adjusted through changing a score target for the level, increasing the available time or moves or giving the player for instance a booster to enhance the gameplay.

There can be certain performance indicators used to measure the success of the game. These indicators can for instance relate to player retention, the virality of the game and the revenue of the game.

The game can be played in a multi-player mode where the player competes against one or several players. The players can be played against locally on the same machine, over a short range network such as the same WiFi network or through Bluetooth connection or the players can be connected over the Internet.

The players can play the multi player mode synchronous or asynchronous.

In one multiplayer implementation of the game the players play the game and can see the other player at the same time in a second part of the screen. The players can in this way compare and compete against each other.

A person skilled in the art will realise that the different approaches to implementing the game is not exhaustive, what is described herein are certain preferred embodiments. It is possible to implement the way in a number of variations without departing from the spirit or scope of the invention.

Game Play Overview

A non-cash game with mobile focus where users can play against each other in a tournament format. The format is turn based asynchronous. Player's can choose to compete either against strangers or people they know. In one implementation, a game against another player consists of three rounds. Once all rounds have been completed the final results with the winner are presented.

The game can be used in a tournament mode where different players play against each other. The players can play using the same seed of game elements or different ‘random’ seeds.

Account Creation

When starting the game the user will be taken through a number of steps before reaching the main menu screen of the game (See FIG. 3). In one implementation these steps vary depending on if the user has already played the game on the device or if it is a new player.

When a new player accesses the game for the first time then there may be the options to either log on to the game via a social network or through the game company's own user database. If choosing the latter option then the user can either create a new account or use an already acquired one.

The application will typically connect to a server to verify the pre-existing login details or create a new account for the user.

Regardless of the login method, players that log in for the first time will receive a welcome gift. In one implementation the players receive 100 ‘gold coins’ which can be used for in-game purchases. In another implementation a top up of 20 coins will be given every 30 minutes with a pre set limit of for instance 40 coins.

If the player isn't starting the game for the first time then the app may recognize the user and therefore not require any login but instead take the user straight to the main view.

The Duration of a Game

In one implementation, when a game has been started between two players, it will not end until three rounds have been completed. If player A starts a new game and therefore plays its first round, then player B will not be able to see the result of player A's first round until having finished the same round. In the same way, player A will not be able to start its second round until player B has completed its first round. If for example player B would finish its first round and continue to play its second round before player A has finished its second round, the player B will in turn have to wait for player A until the third round can be started. The game continues the same way until all three rounds have been played (see FIG. 4), players have to be on the same round in order to be able to play, otherwise they will have to wait for the other player.

In another implementation the game is more strictly turn based and the Player B has to always wait for Player A to complete the current round. In this way, Player A will always be the first one to start a round and Player B will always be the last one to end a round, see FIG. 5.

When both players have finished the third round (applicable in both implementations mentioned above), then the final result will be shown. It will show who the winner is and how much both players have earned on each round. The player with the highest total score wins. In order to give the player an incentive to play all rounds, the rounds have an increased score volatility which gives a better potential for higher scores.

In one implementation when a game is finished the player can choose to immediately start a rematch with the same player, typically by using a button labelled ‘rematch’. This is shown in FIG. 6 which also depicts how points earned on each round can be shown together with a total score of each player.

In FIG. 7 the result of the past tournament is presented to the user with the score for each game and also a bar that is filled to each side depending on the relative score balance between the two players. So for instance if the total score for both players in one round was 1000 points and player A received 400 points and Player B 600 points the bar would be filled in the colour of A up until 40% of the total length and 60% in the colour of B. FIG. 8 also adds the element of colour to signal how well a player has completed a level. This can for instance be shown in that the winner in the level has the bar filled with a gratifying colour such as green. The loosing player's bar may not be filled with any colour or a colour that signifies that he has lost that round. In games that consist of multiple rounds, one bar can be used for each game to show the relative scores of the players. In a typical implementation a game consists of three rounds and therefore also has three bars to indicate scores, one for each round.

In some implementations, the visual indications of the players' relative scores can be accompanied with the numerical value of their scores, typically superimposed over the bars associated with the players.

Main View

Once the player has logged in, the main game view is presented. From here the player can start a new game or view the status of already started games. As can be seen in FIG. 9, several games can be active at the same time. The status on already started games tells the player whose turn it is, theirs or their opponent's; or if a game has been finished the player can see if they won or lost. Tapping with the finger on a current or finished game will take the player to a more detailed view showing the points earned from both players from the rounds having been played.

Starting a New Game

If choosing to start a new game then the player must first find another player to play against. In one implementation this step is called ‘Find a Friend!’, see FIG. 10. Different alternatives on how to find a friend are available. The player may for example choose to play a random stranger, a friend from a social network such as Facebook, they can choose a rematch against a player they have already played against or by searching for another user via their e-mail address or in some implementation by their user names. In one implementation, the various ways to find a friend alters depending on how the player has logged in. If for example having logged in via their email then only ‘Quick game’, ‘Rematch’ and ‘E-mail’ would be available while if logged in via a social network the ‘E-mail’ option may disappear.

If the user searches for an email address or a user name and that is determined not to exist the player can be offered the option to invite the friend to the game. The user may then select from different alternatives to use for inviting the friend. Such alternatives can be via email, SMS or other messaging service. The message to the friend to be invited can contain a link to for instance an app store or other platform where the invited player can download the app and install it on a computing device such as a mobile phone. The invitation message may also contain a second link where the player can click to be redirected to the specific initiated game with the friend that invited the player to the gaming app.

If wanting to start a rematch then the player will be taken to another view showing a list of what friends they can challenge and start a new game with (see FIG. 11). In the same way, if wanting to start a new game with a friend from a social network then a view showing available friends from that network will be shown, see FIG. 12. In one implementation, the view showing friends from a social network is designed with a list of names in alphabetical order. In the same implementation there is also an option to only view friends that are active on the network filtering out friends that may not see the game invitation.

Knowing a friend's e-mail address can also be helpful if wanting to find a friend to play against. The player can type in their friend's e-mail address and if the friend is registered to the system then their name will show up and the player can invite them to a game (see FIG. 13).

After having chosen who to play against, friend or stranger, the user plays his first round. After this, the opponent will automatically have a new game added to their view of current games and can from this view tap to view the details about the current game. The invited player will not be able to see how many points the opponent has earned until having played the same round as well. Without knowing the score, the player can choose to either continue the game or to decline it (see FIG. 14).

The present invention may be implemented with one or more of several different games or different types of games to be played in all or some of the rounds in a tournament. The different games may be random or for instance selected by the challenging player. In an alternative implementation the game to play for each round of the game may be selected as the game progresses. This may for instance be implemented so that the loosing player may choose the game type for the next round.

Continue an Already Started Game

If the player wants to continue a game instead of creating a new one, then active game sessions can be reached from the main view. The main view has a list of all current games and shows whose turn it is. Tapping on one of the game sessions (see FIG. 9) will take the user to another view that shows a more detailed status of the current game. If it's the player's own turn then the detailed view will have a play button together with the result so far (see FIG. 15). From this view the player can also choose to resign if they do not want to continue that specific game session.

As an example of one implementation, FIG. 15 shows that the opponent Johan has played his second round and is now waiting for the other player Mark to also play the second round. Johan's points from round two are hidden and will not be shown until both players have completed the second round. From this view Mark can tap the play button which will take him to the booster view before starting round two (See description elsewhere).

If it is the opponent's turn to play a round then the player will not be able to continue the game but will have to wait until the opponent has made their turn. The player can still tap on the game session in order to view the result so far, or if they choose, to resign from the game. This is depicted in FIG. 16 which also shows how the score of the player is hidden (see the tilted lines in the background of the points on the second row) to the opponent until the opponent has played the same round.

The player may also have a game session where it says ‘Waiting for opponent’. In this case an opponent has not been found yet and the player has to wait until one has been found. While waiting for the game to find an opponent the player cannot resign from the game, see FIG. 17. In the same figure, the tilted lines indicates that the amount of points earned from the player is not yet visible to a potential opponent but will only become visible when an opponent has completed the first round.

Boosters

In one implementation, before each round starts, the players have the option to choose up to three boosters that will be used while playing that specific round. In another implementation up to five boosters can be chosen. To choose a booster, the player simply taps on the booster they wish to use, or with their finger drag and drops the booster to a specific booster area (see FIG. 18). In some implementations, the booster area includes outlines. In another implementation it is also possible to buy a booster in the end of a round. In one implementation this booster costs 30 gold coins.

Boosters available to use can be extra bombs, extra time, and other items that are beneficial to the player. Depending on what type of game is implemented during the rounds, suitable boosters will be implemented.

In one implementation, the first booster is always for free while it costs 10 and 20 pieces of in-game currency for the second and third booster. If the player does not have any in-game currency then there is an option to purchase this. In some implementations, the first booster is not for free. In some implementations one of the three boosters offered is free.

Score Meter

In one implementation of the game there is a meter showing the score earned by the player and their opponent while playing a round. In one implementation the meter shows the final score of the opponent. FIG. 19 illustrates this where the black line in the upper part of the score meter indicates the points the opponent earned during his round. In one implementation the player has to reach above this line before time runs out in order to win the round.

In another implementation the score meter shows what points the opponent had at the same time as the player. For example 10 seconds into the game it will show less points earned for both players compared to 20 seconds into the game (see FIG. 20). The player will now know what the final score of the opponent is until the round is ending. In another implementation the game rounds are played simultaneously in real time by both players, the meter will then show in real time how many points the opponent has.

User Journey

As a summary of the user journey from starting the app to finishing a game: After having logged on to the app, the player is taken to the main view where the player can start a new game or continue its on-going games. The player can also reach the results of completed games from this view. After the player decides to start or continue a new game the player chooses what boosters they want to use during the round that is about to start. Having chosen boosters the game starts and the player plays. After the game session is finished the player is taken to a result screen where their own as well as opponent's results are depicted. From this screen the player can go back to the main screen again. See FIG. 21 for an overview of the full iteration.

Some Technical Aspects

In one implementation the system is implemented using a server that exposes APIs that can be used/accessed by the client side.

API               Description
MatchApi          An API for playing matches against other players. Here
                  you can challenge a player, play a round in a match, get all on-going
                  matches for you etc.
AppleStoreApi     Is a wrapper API for the back end AppleStoreManager where
                  you can verify the app platform store receipts and deliver the
                  products to the player.
BoosterApi        An API for buying booster into a round in a match. Deducts
                  hard currency for the booster bought.
ReygoProductApi   Wraps the back end ProductApi and adds pre selections,
                  sorting and some more metadata around the coin packages that
                  can be bought.
TopUpApi          Delivers information to the client on when the next top up is
                  available and a method to request a topUP.
ReygoSettingsApi  Delivers application specific settings to the client, including
                  game settings, available boosters.
AppKingdomApi     Used to create kingdom-accounts, login, changing display name
                  etc. The client use https to ensure that passwords are not sent
                  in clear text.
SocialUserapi     Used to get a user info about players, to be able to present a
                  social network profile picture, name etc.
AppApi            Used when connecting with a social network, reporting device
                  tokens (used for push notifications)
VirualCurrencyApi Used by the client to get the coins balance.

An Example of a Game

Game Description

The following describes an implementation of the idea using a ‘clicker’ mechanic where groups of 2 or more objects (referred to in this document as blocks, bricks or elements) are selected and automatically removed. FIG. 22 shows an example of a clicker game where one group of two game elements of the same kind is highlighted, meaning that this group can be clicked and removed. The present invention may also be implemented with a ‘switcher’ mechanic where two objects are switched to create chains of typically three or more objects which are then automatically removed. FIG. 23 shows one such exemplary implementation. Another alternative implementation may be to use a match-3 bubble shooter game as shown in FIG. 24.

The following sections will refer to a game with a clicker mechanic. The ideas explained may also implemented for games with other mechanics.

The game can in different implementations provide rewards for good gameplay. This can be in the form of a special game element that preforms a certain function. These special game elements can remove all visible blocks of one colour, all visible blocks in one column or in one row. One example of one such special game element is the bomb described in the implementation below.

There are different implementations on how to activate these special game elements. They can for instance be activated based on time, that they are included in a group of game elements that are removed or they can be activated by the player.

The special game elements can in certain implementations be bought or selected before the game is started and then used in the game when the player so wishes.

Game Goals

The aim of the game is to remove as much of the building as possible within the allotted time by clicking groups of blocks of the same colour. Once removed, any blocks above the cleared combination fall down to fill the gaps created.

A beam rests on top of the structure and falls down when the last block supporting it is cleared. The beam then crushes certain number of blocks as it is falling. The number of blocks crushed is determined by the height of the fall. The implementation of how many levels the beam can crush can vary.

You complete the game by reaching the ground before the time is up. If any blocks are left in the building when time runs out, you will not get any completion bonuses.

The game plays like a classic clicker where the player aims to remove as many ‘floors’ of the playing field (for instance 9×9) structure as possible before time runs out by clicking on coloured variations of blocks in combinations of two or more. The game can have different number of colours available throughout the game. Having 4 or 5 different colours creates a certain flow of the game play.

Once removed, any blocks above the cleared combination fall down to fill the gaps created by the removed blocks. However, only combos within the visible playing field may be cleared.

The player can in an alternative implementation scroll the screen downwards and continue clearing the blocks.

As the blocks in the supporting top floor are removed, the steel beam falls down, and the higher the fall, the more floors will get crushed before the beam comes to a stop. In an implementation it is enough with one supporting block to hold up the beam, irrespective of where on the beam it is supported as exemplified in FIG. 25.

However, by collecting ‘characters’ (in an exemplary implementation in the form of birds) along the way, the beam is able to remain in mid-air as shown in FIG. 26. Since each character is able to keep the beam aloft for a certain amount of time, the more characters are added, the longer before the beam falls down, giving the player time to remove more blocks in preparation for the subsequent fall.

The characters supporting the beam can be collected after having removed certain number of floors in the structure. The characters can in alternative embodiments be added by good gameplay such as a consecutive number of combinations within a limited time or without clicking on an alone block.

By clicking a certain number of consecutive combos within a certain amount of time of each other, it is possible to enter bonus modes which temporarily removes colours and thereby increases game flow.

Added as helpers, the main characters appear at randomly regular intervals on a telephone pole scrolling along the playing field on the left side of the screen. As the characters scroll past a certain point, the sleeping characters wake up and join the crew on top of the beam. Once there, they enable hang time for the beam at one second per character to give the player more time to prepare the building for the ensuing fall.

Added as boosters, bomb blocks appear at regular intervals randomly placed throughout the playing field. Clicking a bomb block immediately causes it to detonate and clear all other regular blocks, regardless of colour, within a 2-block radius, see FIG. 27. However, letting the beam crush the bomb will cause a line blast to clear all regular blocks on the same row.

The bomb may in some instances be detonated with game elements still undestroyed in the area above the bomb detonation. These still intact game elements may fall down to fill up the area below. FIG. 28 shows one implementation of the detonation area when a bomb block has been clicked. FIG. 29 shows when game elements above the detonation area of the bomb block in FIG. 28 have fallen down.

In case there are no more moves to be made in the visible screen (i.e. all visible blocks connect only to blocks of another colour), an informational text will appear to underline this fact, while a ‘wrecking ball’ clears the screen from blocks, allowing the beam to fall and enable further play.

Since the game is both time- and level based, the final result is decided upon different parameters depending on the final outcome of the session.

The Beam

When you have cleared all blocks in the supporting top floor, the overlying beam falls down. The higher the fall, the more floors will get crushed before the beam comes to a stop.

When you collect birds along the way, the beam will be kept in mid-air as it loses support. Each bird adds a certain amount of time (for instance one second) of hang time, so the more birds are added, the longer before the beam falls down. This offers time for you to remove more blocks to extend the subsequent fall.

The number of blocks the beam can crush can be capped. This limit can be based on the total number of blocks it crushes or the number of floors it falls through.

In one implementation the characters supporting the beam can fall off if the beam is only supported with one block as exemplified in FIG. 30. This feature can be implemented with a time delay so that the player can balance the beam back and forth to keep the characters on the beam. This can be implemented so that the time it takes for the beam to rock far enough for the characters to fall off, differs depending on how far out to one side the single supporting block is.

Bonus Mode

To start the bonus mode, you need to create consecutive combos quickly. When you enter the first bonus mode by creating nine successful combos within one second of each other, one colour will then be removed. To remove another colour, you need to enter the second bonus mode by creating another nine successful combos within one second of each other. Breaking a window by clicking a single block will reset the bonus counter.

Game Controls

You control the game with your mouse. Click groups of blocks of the same colour to remove them. Bombs are blown up by either clicking them or crushing them with the beam. To make the beam fall, simply remove all blocks supporting it. Birds are collected by simply passing them with the beam.

If you wish to end the game prematurely, simply press End Game at the bottom right of the screen. You can also toggle the sound and music On or Off separately.

Game Scoring

Combos

You get points for each combo you make. The bigger the combo, the larger the score.

2 blocks: 400 points

3 blocks: 900 points

4 blocks: 1600 points

. . . and so on using this formula: number of blocks×number of blocks×100

Bombs

You get points for each bomb you detonate. You get different scores depending on how they detonate:

Bomb detonated by your click: number of blocks×number of blocks×50

Bomb detonated by the beam: number of blocks×number of blocks×100

Beam

You get regular combo points for all blocks you crush with the beam. A multiplier is applied to those scores, increasing by 0.1× for every floor you pass until it reaches a cap at 2.0×.

Time

You get points for reaching the ground depending on the amount of time left. The base score for the time bonus is 100,000 points, and any time left when reaching the ground translates into a percentage of this.

Alternative Scoring Implementation

Standard Scores

2 blocks: 40 points

3 blocks: 90 points

4 blocks: 160 points

Followed by: (number of blocks) 2×10

Special Scores

Beam Floor Crush Bonus:

1 floor: 1×1000 points

2 floors: 2×1000 points

3 floors: 3×1000 points

Followed by: (number of floors)×1000

Bombs

(Number of blocks) 2×100

Out Of Time

Percentage of total floors cleared×1000

Ground Reached

Upon completely clearing the playing field, the remaining time is calculated as a percentage of the total time given; which in turn translates into a percentage of a time bonus of 10.000 points added to the final score

Strategy

Try to keep a steady pace while playing—not only to keep the flow going, but you may also reach a bonus mode or two that way. Work your way down from the top floors to the bottom ones as this ensures less surprises, allowing you to plan ahead.

Use any beam hang time to your advantage by removing as many blocks as possible before the beam falls down. Finally, don't be disheartened if you find yourself out of moves—the wrecking ball will make sure you're back on track in no time!

Since bigger combos are better and the bonus modes provide just that, listen closely to the sound of the combos and pay attention to the changing background to know when you reach the bonus modes.

Bombs generally give larger scores if detonated by hand rather than if they're crushed by the beam, so try to blow them up with as much surrounding blocks as possible.

To enable higher falls, try to leave a single column as support for the beam and focus on removing as much of the surrounding blocks as possible before removing the supporting pillar.

Characters

Characters appear both as main characters integral to the core mechanics of the game, and as secondary characters adding flare and flavour to the game's setting and story. The main characters, the pigeons of the Block Busters demolition company, naturally play the leading roles as the foremen of the demolition site. As such, they initially sit fast asleep on the scrolling telephone pole on the side of the playing field, before automatically waking up and jumping on top of the beam when passed by. Once there, they each grant the beam one second of extra hang time before releasing it one at a time.

The characters can appear randomly, as a result of good gameplay or at set or random level intervals. The characters can for instance appear randomly at intervals of 50-100 floors, 150-200 floors, 250-300 floors, 350-400 floors and 450-500 floors.

Bombs

Bombs appear as single blocks within the playing field that explode and clear all regular blocks, regardless of colour, within a 2-block radius when clicked. Generated every 10-15 seconds in a randomly selected column within the top rows below the playing field, bombs offer experienced players a welcome boost, while getting the flow going for more inexperienced ones. Acting as any other block, bombs will naturally fall to fill in gaps created underneath as well as automatically get detonated by the falling beam. However, rather than clearing a radius when crushed by the beam, the bomb block will create a line blast beneath the beam, clearing any regular blocks within its own row.

Line Blast Elements

Elements that could be bough as a booster or received in the game. The line blast elements may remove one row or column of blocks.

Paintbrush

A booster that lets the player change the colour of a block or to make it matchable with any other colour.

Bonus Modes

Bonus modes are the special states of gameplay which the player is able to reach by playing fast and accurate. Successfully clicking a certain number of valid combinations of blocks within a certain amount of time from each other will ultimately cause the game to enter the bonus modes. Here, one colour is temporarily removed and the audio-visual feedback intensified to underline this fact.

There are two reachable bonus modes in this implementation of the game; the first is reached from the default mode by clicking 9 consecutive combos within 1 second of each other. As the 9th combo is clicked, all blocks of that colour (the last colour clicked) are simultaneously cleared and will only return once the bonus mode is over. At this point, the audio-visual feedback is intensified using louder explosions, larger effects and screen shakes.

Once entered, the bonus mode runs for a default amount of time of for instance 5 seconds. However, depending on the speed and accuracy of the player, the first bonus mode may be extended into the second bonus mode; by clicking 9 consecutive combos within 0.5 seconds of each other, the game enters the second bonus mode, which removes yet another colour (the last colour clicked) from the playing field, intensifies the audio-visual feedback even further while running for the same default amount of time of 5 seconds before returning to normal mode.

Other Aspects

The game board has a background that can be altered to enhance the story or gameplay.

To enhance the gameplay sound and visual effects can be implements. Below are examples on where in the game those can be implemented.

• • Combo made×5
  • Combo failed×3
  • Beam crush×5
  • Time combo×12
  • Bonus mode combo made×2
  • Character acquired
  • Character reactions×5
  • Bomb explosion
  • Wrecking ball screen wipe
  • Trophy collected

There are different possible implementations to help the player identify the next possible move in the game. For instance, mouse-over can highlight the possible combo including the block that is hovered over. The suggestion of the next possible move can also be automatically done after a certain amount of time of inactivity from the player, for instance 3 seconds. The next possible move can be suggested through highlighting the blocks or having for instance an arrow pointing on the move.

If the player tries to select a single block that is not adjacent to another block of the same colour then that block will not be removed. There can be a booster the player can use to remove any one block.

There can be a vertical time slider on right side of playing field.

There can be a dynamic time with a set time on the counter (1 minute), 20 seconds are then added every 50 floors and 5 seconds deduction for every invalid combo. The times can vary depending on the implementation of the game. More time can also be added for good game play or a number of consecutive combinations or big combinations.

The game can highlight the area that a bomb will clear if the user hovers the pointer over a bomb.

The beam can in an alternative implementation of the game hang in the air before falling downwards for a set number of clicks, for instance three clicks. The player would then have the possibility to clear additional blocks before the beam starts to crush the blocks.

The game can implement different game modes; limited time, limited number of moves, collect as many points or other alternative modes.

Social Aspect

Connection to a Social Network

Games created using the invention described herein can be connected to or linked with a social network such as Facebook™ or Google+™ or a games platform with different players who can interact and see each other's progress. It is common that the users on such networks have avatars with for instance a photo of the user and/or the user's name. Such avatars can for instance also be a sign or a figure.

The social network can be located on a server that is different from the server on which the game is located, the game and the social network can also be located on the same server. In some implementations there is a direct live connection between the social network and the game platform that continuously synchronise them, in other implementations the two platforms synchronise at certain intervals, such as when the player logs into the game. The players progress when having played in offline mode (for instance completed levels and score), for instance if the player is travelling in a tunnel, can be synchronized when the player is connected to the internet.

The user and his friends' avatars can be displayed in the game or in relation to different tournaments in the game. The avatars can also be shown in relation to indicators of the player's skill level or high score. In some implementations the avatars can be derived from a social network to which the game is connected, in other implementations they can be derived from a database related to the game. It is possible for the avatars related to users to change depending on the overall progress or performance in the game. For instance, an avatar can become larger or more visually advanced as the player plays the game for a longer time or has received a high score.

The user can connect with other users of the social network, either as “friends” on the social network or as “friends” within the game environment. The player can interact with other players he is connected to on the social network or who are playing the same game.

The game can be implemented to synchronize game state information and/or retrieve and connect to the social graph information and user profile of the player on a social network. It can also be connected to a proprietary network related to the game or the game developer.

The game may also be implemented so that it is connected to a plurality of social networks. The user can be given the option to select what information that can be derived and shared with which social network.

One example of how the game can be connected to a social network is the Facebook™'s Open Graph API allows websites and applications to draw and share information about more objects than simply people, including photos, events, and pages, and their relationships between each other. This expands the social graph concept to more than just relationships between individuals and instead applies it to virtual non-human objects between individuals, as well. A game can typically share in-game events such as that a level has been completed, that a player has passed a friend in the game or beaten a friend's high score on a level. The game can also post events, such as that a player has purchased objects in the game or received objects from other players of the game.

Cross-Device and Cross-Game Functionalities

Some implementations of the game allows for the game state and for instance results of past games and score to be synchronised between different devices or platforms.

The synchronisation can happen while playing the game, if the player is connected, or it can be synced at certain times when the player chooses to connect to the game server. It is also possible for the player to play the game entirely in offline mode, but in that case there won't be real-time data available that relates to for instance the performance of other players. In a typical implementation, synchronisation of game progression between platforms can only happen when the player is connected to the game server.

The game can for instance be played in an offline mode on a handheld device using locally stored information on the handheld device. The device can store all or some of the rounds that are available for the player to play in the game. Some of the features in the game can be locally run on the device and dependent on the local machine. Other features, such as data related to other players, will not be available in real time when playing offline, but rather gathered a certain points in time. One example of a locally run feature can for instance be that if the game is implemented to regenerate lives or in-game currency after a certain period of time, then the time can be locally decided based on the clock on the device. In some implementations, the central game server clock can override the local clock when the local device is or has been synchronised with the server.

A game can be implemented so that the player knows if it has synchronised the available data with the central server or servers. This can for instance be through a coloured symbol or a check mark that indicates that the information is up to date. The servers with which the game can synchronise include but are not limited to; a server running the game, servers hosting a social network to which the game is connected and a server hosting other games the player is active on.

The game can also indicate if it has been able to establish a connection with the central server for synchronisation or if for instance the network connection is down. That the device is offline can for instance be illustrated with a greyed out icon.

In some implementations, players can be rewarded for playing the game on multiple platforms. For instance, players that active on a computer-based platform could get a bonus for also installing the game on a handheld device. Such bonus may for instance be in the form of in-game currency, a booster to be used in the game or other in-game valuable object.

Players can also be rewarded for playing multiple games that are related, for instance games from the same developer. When choosing to play a new game, the player can receive bonuses in another game. This can be triggered by using a link from one game to the other, or by games sharing information between one other so that it automatically detects a player that is playing more than one game and subsequently rewards them. One way of rewarding players that play multiple games and/or play games on multiple platforms can be to give access to certain missions that are only available after fulfilling certain such criteria.

One example of an implementation with synchronisation across platforms is as follows:

A first server, for instance one hosting a social network, with a first data store storing data relating to the state of a game. The first server is configured to communicate with a first plurality of devices, such as mobile phones or personal computers, through a first application programming interface, where the first plurality of devices is related to a first computing platform.

A second server, for instance one hosting a game platform, with a second data store storing data relating to the state of the game. The second server is configured to communicate with a second plurality of devices, such as mobile phones or personal computers, through a second application programming interface, where the second plurality of devices is related to a second computing platform.

A third server with a third data store, configured to communicate with the first and the second server. The three servers are configured to synchronise the three data stores in such a way that when synchronized, the first, second and third data store all relate to a synchronised game state.

Claims

1. A method of displaying scores of players in a game tournament played on connected computing devices, each with an integral display, in which a processor causes the scores for each player for a specific round of the game to be recorded and then causes the scores for that specific round to be displayed in a scoreboard that includes at least one linear bar divided into two sections, the length of each section being determined by the processor to indicate the relative scores of each player.

2. The method of claim 1 in which a processor causes the sections to be in different colours.

3. The method of claim 1 in which the game is a two player tournament and there are two sections, one for each player, and the longer section is coloured differently from the shorter section.

4. The method of claim 1 in which the longer section is brightly coloured compared to the shorter section.

5. The method of claim 1 in which there are X rounds for each tournament and hence X linear bars, each indicating the relative scores for each player in each of the X rounds.

6. The method of claim 1 in which there are three rounds for each tournament and hence three linear bars, each indicating the relative scores for each player in one of the three rounds.

7. The method of claim 1 in which the linear bar for a specific round of the tournament does not indicate the relative scores for either player until both players have finished that round.

8. The method of claim 1 in which the display shows a button that, if selected by a player, initiates a signal to be sent that causes the or a processor to display a screen that includes multiple available boosters or charms available to a player.

9. The method of claim 8 in which the display shows multiple available boosters or charms, and the player is permitted to use one booster or charm for free.

10. The method of claim 9 in which the display shows multiple available boosters or charms, and the player has to pay for them using an in-game currency, and that in-game currency is topped up automatically to a pre-defined level at pre-defined time intervals.

11. The method of claim 10 where the pre-defined time interval is 30 minutes.

12. The method of claim 8 in which the display shows multiple available boosters or charms, and the player can select a booster or charm by dragging and dropping it onto a target area.

13. The method of claim 9 in which the target area includes outlines corresponding to each possible booster or charm that can be dropped into the target area.

14. The method of claim 8 in which the display shows a second option or button that, if selected by a player, cause a signal to be sent to a processor to commence game play.

15. The method of claim 1 where the display shows a button, such as a ‘rematch button, that, if selected by a player, causes a signal to be sent that initiates another game play tournament between the players.

16. The method of claim 1 in which each section also displays the numeric score achieved by one player superimposed over a section of the linear bar associated with that player.

17. The method of claim 1 in which the display is a touch screen display.

18. The method of claim 1 in which the game is an asynchronous social game

19. The method of claim 1 in which a processor is located at a remote server.

20. The method of claim 1 in which the computing device is a portable, personal wireless device, such as a smartphone or tablet.

21. A computing device adapted to play a computer game, the device including a processor, a memory, a display, a touch screen or a cursor based input device, and computer code stored in device memory or on a remote server and executable by the device processor or a remote processor, and in which the computer code generates computer game graphics for the display on the device;

in which a processor causes the scores for each player for a specific round of the game to be recorded and then causes the scores for that specific round to be displayed in a scoreboard that includes at least one linear bar divided into two sections, the length of each section being determined by the processor to indicate the relative scores of each player.

22. A non-transitory computer readable medium encoded with instructions for controlling a computer system to display a game on a display; and in which the instructions running on the processor(s) result in:

the scores for each player for a specific round of the game to be recorded and then causes the scores for that specific round to be displayed in a scoreboard that includes at least one linear bar divided into two sections, the length of each section being determined by the processor to indicate the relative scores of each player.