Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
SYSTEM AND METHOD FOR PLAYING CONTRACT BRIDGE GAME WITHOUT USING PLAYING CARDS AND ASSOCIATED PARAPHERNALIA
Document Type and Number:
WIPO Patent Application WO/2014/013504
Kind Code:
A1
Abstract:
Contract bridge is a popular game among millions of people worldwide. For playing and conducting contract bridge in clubs and tournaments, huge number of stationeries like table numbering tags, movement charts, playing cards, bidding boxes, bidding cards, score sheets, computers and printers are required. Manual handling of these stationeries before, during and after play is most cumbersome. The present invention is a system and method for playing contract bridge game without using playing cards and associated paraphernalia. It is based on the server-client architecture wherein a computer is used as the server and tablets or similar communicators are used as client interface. As the whole system and method of playing the game is computerized, the game becomes very easy and almost error free.

More Like This:
Inventors:
CHANCHAL DASS (IN)
Application Number:
PCT/IN2013/000188
Publication Date:
January 23, 2014
Filing Date:
March 21, 2013
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
CHANCHAL DASS (IN)
International Classes:
A63F13/00; G06F15/16
Domestic Patent References:
WO2008092455A12008-08-07
Foreign References:
IN2062MUM2012A1
US20120187629A12012-07-26
US20070005704A12007-01-04
US20060183524A12006-08-17
CN101320406A2008-12-10
Download PDF:
Claims:
I claim,

1. A system and method for playing contract bridge game without using playing cards and associated paraphernalia.

2. The system and method for playing contract bridge game as claimed in claim 1 wherein, the software application for the same is based on server-client architecture.

3. The system and method for playing contract bridge game as claimed in claim 2 wherein, the software uses a combination of the Waterfall model and the Agile development model.

4. The system and method for playing contract bridge game as claimed in claim 3 wherein, each player has a device loaded with the client application through which they can communicate with the server through a network.

5. The system and method for playing contract bridge game as claimed in claim 4 wherein, the device loaded with the client application can be a tablet or any such communicator.

6. The system and method for playing contract bridge game as claimed in claim 5 wherein, there is a referee computer for the referee, loaded with the central server application.

7. The system and method for playing contract bridge game as claimed in claim 6 wherein, all of the clients and the server are connected through a local area network (LAN) for making communication.

8. The system and method for playing contract bridge game as claimed in claim 7 wherein, the client and the server applications rely on the TCP (Transmission Control Protocol) channel for all of the communication and The messages communicated are in XML (Extensive Markup Language) format.

9. The system and method for playing contract bridge game as claimed in claim 8 wherein, the server interface lists the rounds on the left side and the partnerships along with their tables, board numbers and scores for the corresponding round on the right side and a small box at the bottom left which shows the connection status of all the clients.

10. The system and method for playing contract bridge game as claimed in claim 9 wherein, the client interface offers the user to choose a background from the three available backgrounds, their preferred deck from the three types of deck options available and the card design from the four card designs available.

1 1. The system and method for playing contract britfge game as claimed in claim 1 wherein, the method for playing the game comprises the following steps:

(a) starting of the server application by the referee of the match and entering the details including the number of pairs, the type of movement, the number of boards per table and the type of scoring;

(b) starting the game by the server and starting the devices by the players;

(c) entering the details regarding their table number and their playing position by the players;

(d) dealing of the cards to each player by the server;

(e) bidding by the players using the bidding box provided in the centre of their screen;

(f) playing of the cards by the players by first selecting the card by clicking on the selected card and then again clicking on it to confirm the selection;

(g) sending the score to the server by the player in the North position after the game is over;

(h) pressing the "New Game" button by the player to start playing with the next board; (i) instruction by the server as to which seat the player has to take after the round for the next round;

(j) declaration of the completion of the tournament by the server when all the rounds have been played on each player's screen; and

(k) generating the tournament ranking based on individual game scores by the referee using the result utility on the server application.

12. The system and method for playing contract bridge game as claimed in claim 1 1 wherein, in step (f) if the player doesn't want to use the two step clicking process for selecting and then playing the card, he can turn off the option for the step "b"f selection by a switch provided on the right of his cards.

13. The system and method for playing contract bridge game as claimed in claim 1 1 wherein, either the tournament or a match from the entire tournament can be exported after it is over to a single file which can be carried around or transferred to anyone and an round, table or board can be selected and replayed by the user.

14. The system and method for playing contract bridge game as claimed in claim 1 wherein, Qt Development Toolkit is chosen as the development platform for both the server and the client applications.

15. The system and method for playing contract bridge game as claimed in claim 14 wherein, both the server and the client applications have a NetworkUtils class that implements and provides a reliable and convenient to use communication channel, and a XMLEngine class for convenient building and passing of outgoing and incoming messages respectively.

16. The system and method for playing contract bridge game as claimed in claim 2 wherein, the server implementation is split into four modules namely Server, MovementModel, Logger and Replayer.

17. The system and method for playing contract bridge game as claimed in claim 16 wherein, the server implements a Server class that handles all the communication and lets the application know of the activities received in incoming messages.

18. The system and method for playing contract bridge game as claimed in claim 17 wherein, the server forwards the interpreted incoming messages to the MovementModel class which in turn issues outgoing response if necessary to the Server after which the" Server uses the XMLEngine to wrap the response data in XML and sends it using NetworkUtlis.

19. The system and method for playing contract bridge game as claimed in claim 18 wherein, the Server generates the boards to be played and maintains a list of such Board objects.

20. The system and method for playing contract bridge game as claimed in claim 19 wherein, the Server sends the particular board specified by the MovementModel to the intended clients at the start of each deal.

21. The system and method for playing contract bridge game as claimed in claim 16 wherein, the MovementModel keeps track of all the pairs, tables, rounds and scores of the matches in the tournament using various movement algorithms.

22. The system and method for playing contract bridge game as claimed in claim 21 wherein, the MovementModel supports Mitchell movements for upto 50 tables and Howell movements for upto 20 tables.

23. The system and method for playing contract bridge game as claimed in claim 22 wherein, the MovementModel manages the cumulative tournament scoring.

24. The system and method for playing contract bridge game as claimed in claim 23 wherein, the MovementModel supports both Matchpoints and IMP (International Match Points) tournament scoring using their own pointing algorithms which are implemented by the ScoreSheet class.

25. The system and method for playing contract bridge game as claimed in claim 24 wherein, the MovementModel maintains a list of such ScoreSheet object corresponding to each of the Board objects.

26. The system and method for playing contract bridge game as claimed in claim 25 wherein, the MovementModel, at the end of the tournament, asks each ScoreSheet object to compute the points on each board for each pair using whichever of the scoring mechanisms specified by the referee in the beginning of the tournament.

27. The system and method for playing contract bridge game as claimed in claim 26 wherein, the MovementModel, then sums up the points scored by each pair and gives out a list of ranks.

28. The system and method for playing contract bridge game as claimed in claim 16 wherein, the Logger implements logging of each and every move that takes place during the tournament.

29. The system and method for playing contract bridge game as claimed in claim 16 wherein, the Replayer module implements reviewing a previously played match in some tournament.

30. The system and method for playing contract bridge game as claimed in claim 2 wherein, the client application is split into two modules namely, Talker and GameEngine.

31. The system and method for playing contract bridge game as claimed in claim 30 wherein, the Talker module implements all the interpretation job of incoming network communication messages as well as wrapping around the outgoing data into relevant format suitable for the network communication.

32. The system and method for playing contract bridge game as claimed in claim 31 wherein, the Talker module uses the XMLEngine to manipulate and build the network messages, and NetworkUtils to send and receive these messages.

33. The system and method for playing contract bridge game as claimed in claim 30 wherein, the GameEngine takes care of what is shown to the user on the screen by loading the game canvas on the screen for the user to interact with it.

34. The system and method for playing contract bridge game substantially herein described with reference to the foregoing description.

Description:
TITLE OF THE INVENTION

System and method for playing contract bridge game without using playing cards and associated paraphernalia

FIELD OF THE INVENTION

The present invention relates to a new systems and methods of playing and conducting contract bridge (duplicate, rubber, teams, pairs) at club and tournaments with a smart phone, mobile or tablet computers. The invention eliminates the use of playing cards and other paraphernalia in playing and conducting contract bridge in clubs and tournaments. More particularly the present invention relates to a computerized method and process of playing contract bridge at club and tournaments.

BACKGROUND OF THE INVENTION

Contract bridge is a century old game and popular in many countries around the globe. Some of the tournaments are pair event and some others are duplicate team event. In pair events, two players form a team and compete with other pairs. In team event four to six players form a team and they compete with other teams participating in the tournament. In a bridge tournament each pair or team has to play against other pairs or teams and all pairs or teams have to play a predetermined number of boards. After the play, each pair gets a comparative score for each board and after completion of tournament, the comparative score of each pair for each board is tabulated and ranking is given based on the summation of scores of all boards. The total activities of a game can be divided into following headings:

1. Sitting, 2. Shuffling,

3. Dealing,

4. Bidding,

5. Playing of cards,

6. Counting of tricks,

7. Writing/ Entering the scores,

8. Moving of players from one table to others,

9. Moving of cards from one table to others

10. Ruling by tournament directors,

1 1. Calculation of scores and

12. ' Declaration of results.

In conventional practices, all these activities are handled manually and different stationeries are used in every stage of play. Sitting arrangements are handled by table numbering tags, shuffling and dealing is done with playing cards, bidding is done through bidding cards and bidding boxes, playing of cards are done by playing cards, counting of tricks are done by putting the playing cards in vertical and horizontal orientation, writing of scores are done by using score sheets/ travelers, movement of players and cards are controlled by movement charts, ruling of directors are given in papers, calculation of scores are done by using tabulated sheets and results are declared in a paper which is put in a wall. So lots of stationeries are required at every stage of game and as all these stationeries are handled manually. So chances of occurring mistakes and errors increase manifold and create lots of problem in play as well as final results. To avoid all these problems, electronic movement charts, electronic scorers are being used. In spite of these advancements, the bridge tournaments are not still made error free. The present process and methods helps in play and conduct of contract bridge in club and tournaments without using any stationeries and in an efficient and error free manner. Present online bridge games also do not use any stationary but these methods are not targeted to replace use of stationeries in clubs and tournaments.

US 8088006 patent having title "Card game system and method" discloses a card playing system or network and method particularly suitable for playing bridge and other multi-table card games in clubs and tournaments. A remote input/ output device or scoring unit is provided at each of the plurality of the tables which acts as bidding box or scorer. The date of the patent is 3- d -.January 2012. It claims manual entry of bids by each player through one bidding box rotated turn-wise which can add another complexity in the system. In this method, the play goes on conventional way and confusion or mistakes may happen in counting the tricks one get. In addition, the scores are also stored manually after the play through the same input device and same input device is to be used for bidding in next deal which makes the system complicated. However, this current technology has helped in overcoming some problems faced during bidding and playing of cards - like out of turn bid, or out of turn play, etc, still there are scope for improvements. This technology does not explain or claim to eliminate the use of playing cards in playing and conducting contract bridge at clubs and tournaments. The current invention uses four input / output devices, one for each player total activities involved in a game is controlled by these devices through a remote server. The bidding and card plays proceeds as the turn comes for a particular player and his system activates. Similarly the result automatically calculated as soon as the play of the deal completes depending upon the bids and the tricks taken. No separate actions is required to be taken to remember the number of tricks taken by each pairs. Similarly, the result is automatically calculated once the total deals are played. There is no need to calculate the results manually.

US 435355 patent having title "Duplicate bridge scoring system" discloses a computer system for duplicate bridge scoring utilizing a compact data card to remain attached to a duplicate board during the session of play. The card is arranged for encoding of data round-by-round. But this system does not claim to replace playing cards and other stationeries for play and conduct of contract bridge at club and tournaments.

US 5839958 Patent having title "Voice synthesized bridge bidding module and method of using same" discloses a system to provide each player an identical battery operated module containing switches which a player uses to enter bids which in turn produces a output of verbal message equivalent to linguistic expression of the selected bid. The object is to eliminate all oral mannerisms. Though the system help in avoiding oral manners, the current invention uses more advanced sound free technique for bidding. The said patent does not claim to eliminate the use of stationeries and also does not claim to eliminate manual entry of bidding and scores which the new invention does.

Although research has been done to improve upon the traditional methods of playing bridge game, none of these inventions eliminate the large amount of stationery required for playing the bridge game. It is very cumbersome, time consuming and painstaking to manage large tournaments while players keep rotating and cards have to be exchanged for playing on other tables after each deal. Moreover, errors occur in calculating the scores as well as while moving boards from one table to another which haven't been eliminated in the prior art. Some people even resort to cheating to win and may not be identified immediately in the traditional bridge game. So an automated bridge game which eliminates all the above mentioned flaws is the need of the day.

OBJECT OF THE INVENTION

The main object of the invention is to provide for a system and method for playing contract bridge game without using playing cards and associated paraphernalia.

Another object of the invention is to provide for a system and method for playing contract bridge game without using playing cards and associated paraphernalia which minimizes and eliminates errors arising out of manual handling of stationeries and conventional process movement of players and playing cards.

Still another object of the invention is to provide for a system and method for playing contract bridge game without using playing cards and associated paraphernalia which make the process of play and conduct of contract bridge at clubs and tournaments simple and efficient.

Yet another object of the invention is to provide for a system and method for playing contract bridge game without using playing cards and associated paraphernalia which adds glamour to the game of contract bridge.

A further object of the invention is to provide for a system and method for playing contract bridge game without using playing cards and associated paraphernalia which helps in skill improvement of the players playing the game. A still further object of the above invention is to provide for a system and method for playing contract bridge game without using playing cards and associated paraphernalia by making it computerized.

SUMMARY OF THE INVENTION

The present invention provides an improved process and method for playing and conducting contract bridge at clubs and tournaments. The invention helps in conducting the entire bridge tournament using the computer in which everything right from dealing the cards, bidding, playing the hand, score keeping as well as declaring the winners is computerized. This enables the bridge teams to simultaneously play the same hand on different tables, which was cumbersome while playing with physical cards. The invention relates to a technology based on the server-client architecture. Each player will have a device loaded with the client application and there is a computer loaded with central server application. All the clients are connected to the central server with a wireless or wired network for making communication. The system relies on the TCP (Transmission Control Protocol) channel for all communication. The messages communicated are in XML( Extensible Markup Language) format.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 displays the on screen appearance of the client interface.

Fig. 2 displays the on screen appearance of the server interface.

Fig. 3 displays the screen appearing on the server at the start of the game.

Fig. 4 displays the screen appearing on the client interface at the start of the game.

Fig. 5 displays the switch for selecting or picking a card. Fig. 6 displays the three types of decks available.

Fig. 7 displays the four types of card designs available.

Fig. 8 displays the compact class diagram for the server module.

Fig. 9 displays the compact class diagram for the MovementModel module.

DETAILED DESCRIPTION

The nature of the invention and the manner in which it is performed is clearly described in the specification. The invention has various components and they are clearly described in the following pages " ¾f the complete specification.

Contract bridge is a trick-taking game using a standard deck of 52 playing cards. It is played by four players in two competing partnerships, with partners sitting opposite each other around a table. It is considered to be one of the most intellectual card games existing today. Millions of people play bridge worldwide in clubs, tournaments, online and with friends at home, making it one of the world's most popular card games. The game consists of several deals each progressing through four phases: dealing the cards, bidding, playing the hand and scoring. Dealing the hands and scoring are procedural activities while bidding and playing the hand utilize the skill of the player. In a bridge tournament, the hands are dealt and played in such a manner that each partnership (north-south or east-west) plays the same set of hands as their counterparts at other tables and the scoring is based upon relative performance. This design of the game results in emphasizing skill and somewhat eliminating , the element of chance. Competitions in duplicate bridge range from small clubs with a handful of tables, to large tournaments such as the World Bridge Championships where hundreds of tables play the same hands. The present invention is a computerized version of the game of Contract Bridge wherein no physical cards and the associated paraphernalia like table numbering tags, movement charts, bidding boxes, boards, flappers, scorers etc. are used. The entire bridge game has been developed on the computer in which right from dealing the cards, bidding, playing the hand, scoring, to defining the movements across rounds of a tournament, cumulative tournament scoring and finally declaring the winners of a match, everything is computerized. The invention also makes easy for the bridge teams to simultaneously play the same hand on different tables which was cumbersome when playing with physical playing cards.

For playing and conducting the game of contract bridge at clubs and tournaments^ a software application has been developed based on server-client architecture. This software uses a combination of the Waterfall model and the Agile Development model. So each feature is unit tested as and when developed during the implementation phase before it could go into the mainstream code. Git software is used for version control and the source code is hosted on www.github.com. Each player has a device loaded with the client application through which they can communicate with the server through a network. The device loaded with the client application can be a tablet or any such communicator. There is a referee computer for the referee, loaded with the central server application. The players use the client application on the computers to play each game. The client communicates with the server application which is turned on at the start of a tournament by the referee on his computer. All of the clients and the server are connected through a local area network (LAN) for making communication. This could be achieved by setting up a WiFi network locally at the venue of the tournament. The client and the server applications rely on the TCP (Transmission Control Protocol) channel for all of the communication. The messages communicated are in XML (Extensive Markup Language) format.

The interface for the server application is shown in Fig. 1. The server interface lists the rounds on the left side and the partnerships along with their tables, board numbers and scores for the corresponding round on the right side. A small box at the bottom left shows the connection status of all the clients. The server application manages the movements during the tournament and also implements the cumulative tournament scoring from the individual match scores and declares the winners. It also helps the clients communicate among themselves, for example, a move played by one of the players would be received by the server and forwarded to the other three clients on the table. This way the server can also keep a log of the tournaments taking place, which can be used to review the tournament at a later point of time.

The interface for the client interaction is displayed in Fig. 2. As the game is played in the client interface, it is graphically more involving with various fancy but subtle enough animations for a standard card game. The game interface offers various graphical options. The most basic one is that of the background. The user can choose from the three available backgrounds from the status bar itself at the bottom right corner. There are also deck and card design options available which have been taken from the various options available on the internet. Fig. 6 shows the three types of decks available while Fig. 7 shows the four card designs available to choose from. The client interface actually lets the players play the game by interacting with the graphical elements presented on the screen by the software. Playing the Game

Initially, the referee of the match starts the server application and enters the details asked for as shown in Fig. 3. These details include the number of pairs, the type of movement, the number of boards per table and the type of scoring. After these details have been filled, the server starts the game and the players now start their applications.

When the client interface starts, they have to enter a few details regarding their table number and the player position which is shown in Fig. 4. When all the four players on a table have entered their details, the game interface which is shown in Fig. 2 is shown on the screen. The server deals the cards which are shown on this interface and ' the players can start to bid using the bidding box shown in the centre in Fig. 2. The players can bid by clicking on the relevant bid button. This bid is shown on the interface of the other three players of the same table. The player with the next turn bids similarly and the game continues. After the bidding, the players start playing with the cards.

On each player's game interface, the cards shown at the bottom are his own cards while his partner's cards i.e. the dummy's cards are shown at the relative position i.e. at the top. The cards of the opponents are shown at the two sides of the game interface. The players play the cards by using their mouse. On the first click on a card, the card gets selected and rises by some offset. The player clicks the card again to confirm the move of the card. If he doesn't want to play the selected card, he will click on another card to select it and then if he wants to play the card, he will again click it to play the card. If the player doesn't want a two stepped process i.e he doesn't want to select the card before playing, the selection or picking of the card can be turned off by a simple switch on the right of the player's cards which is shown in Fig. 5. The number of tricks won or lost is shown on the bottom left corner of the screen along with the tricks won by both the teams. At the end of the game, the score is shown on the screen. The client at the North then sends the score to the server, which is kept in record for later relative scoring. The player has to press the "New Game" button at the bottom to start with the next board. If the round has ended, the player will be instructed as to which seat he has to take for the next round. This way, the players shuffle around in a specific pattern after each round. After all the rounds are played, the tournament is declared to be over on the screen of each player. The referee then uses the result utility on the server application to generate the tournament ranking based on the individual game scores. This ranking specifies the points earned by each participating partnership and they are ranked by these points, the pair with the most points being at the first rank.

There are two things that can be imported and/or exported: the tournament, and a match from the tournament. The entire tournament can be exported after it is over to a single file which can be carried around or transferred to anyone. The same file can then be imported into the server application and it will load all the tournament data. The user can then select a particular round, table and the board and use the replay option to have the match replayed. Similarly, the selected match can be exported to a single file, and later imported into the server application to replay it. This file is written in XML format. The tournament file saves the boards and cards in it and all of the moves made by players in various matches that take place in various rounds at various tables. When imported, the server reads this data from the file and loads it on its interface. Similarly, the matches also save the board used in that match, and the moves the players made during that match.

Implementation Details Qt Development Toolkit is chosen as the development platform for both the server and the client applications. The advantages of using Qt toolkit are as follows:

• Qt is open source and free to use development toolkit, so no costs are involved here. It is maintained by a large community with some developers from Nokia Corporation and hence provides a highly reliable set of library modules.

• The applications developed with Qt are cross-platform. This means that the same application can be built for Windows, Linux and MAC operating systems without any change to the source code.

• Qt provides asynchronous network library which is very easy to use and helpful since the " applications need not bother waiting continuously for incoming communication.

• Qt has in-built module for creating and manipulating XML data, which is again useful for easily building XML messages for sending and also manipulating the received XML data.

• Qt's QtQuick module makes it very easy to build a game canvas in a declarative language (QML). It is backed by Javascript engine for implementing the client-side game logic. Both the server and the client applications have a NetworkUtils class that implements and provides a reliable and convenient to use communication channel, and a XMLEngine class for convenient building and passing of outgoing and incoming messages respectively. NetworkUtils uses QtNetwork module and XMLEngine uses QtXml module provided by Qt.

Unix testing is done on four different computers after implementing each feature. UNIX tools like SSH will be used for automating the testing to some extent to some extent (remotely updating, compiling and running the code). Git mainly functions over SSH, so code can be easily updated from the development repository on the test computers. Another tool, SCP, can be used to copy the compile scripts over SSH to the test computers.

Server Implementation

The server implementation is split into four modules: Server, MovementModel, Logger, Replayer.

(a) Server: The Server application is made in Qt's primary language (C++) which will implement complex networking and tournament management. The server implements a Server class that handles all the communication and lets the application know of activity received in incoming messages. The Server forwards the interpreted incoming messages to the MovementModel class which in turn issues outgoing response, if necessary to the Server. The Server then uses the XMLEngine to wrap the response data in XML and sends it using NetworkUtlis. The boards supposed to be played in the tournament are generated by the Server itself. The Board class implements shuffling and placing of cards in 4 pockets, and the Server uses it to maintain a list of such Board objects. It sends the particular Board specified by the MovementModel to the intended clients at the start of each deal. Fig. 8 displays the compact class diagram for the Server module.

(b) MovementModel: The MovementModel keeps track of all the pairs, tables, rounds and scores of the matches in the tournament. It uses implementations of various movements algorithms to keep track of these things. There are two types of movements: Mitchell and Howell. Both of them follow a specific movement pattern. MovementModel uses the Movement class for determining the movement table, among other things. The classes Mitchell and Howell implement the Movement base class. The MovementModel class also manages the cumulative tournament scoring. There are two types of scoring: match point and IMP. Both have their own pointing algorithms. ScoreSheet class implements both the algorithms. Each ScoreSheet object represents a score sheet for a board. MovementModel maintains a list of such ScoreSheet object corresponding to each of the Board objects. All the scores made using a board are recorded in the corresponding ScoreSheet object. At the end of the tournament, MovementModel asks each ScoreSheet object to compute the points on each board for each pair using whichever of the scoring mechanisms specified by the referee in the beginning of the tournament. It then sums up the points scored by each pair and gives out a list of ranks. Fig. 9 shows the compact class diagram of the MovementModel module wherein both the Mitchell and the Howell movements are included.

(c) Logger: The logger implements logging of each and every move that takes place during the tournament. All moves received by the server are also forwarded to the Logger for it to log. These logs are maintained in a single file per tournament in XML format. It again uses the XMLEngine to generate these logs. These logs can also be exported to any other file. This module also implements retrieving of older logs, reading them and loading them in the server interface for reviewing purpose. It loads all the rounds, tables, pairs and scores on the server interface. The Logger also comes into action when a spectator client has joined in and the match data and moves taken place till now are supposed to be sent to him by Server. The Logger mostly relies on itself for its core tasks.

(d) Replayer: The Replayer module implements reviewing a previously played match in some tournament. When the user wants to replay a match that took place previously, the server application starts the Replayer, and asks the Logger to feed the match data to the Replayer from the imported match file. Replayer is essentially the GameEngine from the client application. It shows a screen similar to the client application and replays the entire match. The Replayer module relies on itself, except that it receives the data from the Logger.

Client Implementation

The client application focuses more on the graphics side of the game. It tries to enhance the user interface as far as possible and give good animation and other graphical effects while playing with the cards. It is essentially split into two modules: Talker and GameEngine

(a) Talker: The Talker module implements all " the interpretation job of incoming network communication messages as well as wrapping around the outgoing data into relevant format suitable for the network communication. This is similar to the work of the Server module in the server application. It manipulates the incoming messages into meaningful data and forwards it to the GameEngine module that handles the data thereof. It also wraps up the data received from the GameEngine to suitable format for sending it to the desired receiver. It uses the XMLEngine to manipulate and build the network messages, and NetworkUtils to send and receive these messages.

(b) GameEngine: This module takes care of what is shown to the user on the screen. It loads the game canvas on the screen for the user to interact with it. The animations and the graphical effects are then taken care off by a QtQuick module that defines the layouts and animations of the game elements. QtQuick along with Javascript takes care of all the game logic related to validating user moves, calculating score at the end of the deal, etc. GameEngine forwards the moves received by the Talker to the game canvas for it to show the move; and tells the GameEngine whatever user moves which is forwarded to the Talker for sending it to other players. The graphic elements include the background, the center area, the cards holder, the bidding board (where the bids are shown), the bidding box (from where the player can bid), the scoreboard, the information box and a settings box. This same game canvas is adopted into the Replayer module of the server application, for the purpose of replaying an old match.

Testing of the Application

The application was tested for regressions after each new feature or a bug fix was committed. The following tests were conducted at each such development steps in the application:

(i) Network: This test was done for testing the NetworkUtils module. The initial design made use of UDP (User Datagram Protocol) channel for communicating messages which was not found to be reliable on a wireless network. So the network was changed to TCP channel for communication wherein the socket itself has to be given for sending and receiving messages.

(ii) Game Logic: This test involved testing the Javascript logic of the game canvas which included everything from identifying and authenticating a player to communicating moves at the right time with other players, correctly validating the bidding and the playing card moves, showing the dummy cards correctly after the first card move, disabling the user interaction when its not his turn, correct timing for these validations in between the various animation timings, correctly determining the winning bid, the trump suit, the declarer, the winning trick, correctly determining the next turn of a player, making sure the game canvas is correctly suspended after the end of the deal, etc. The errors found in the logics were fixed.

Game Interface: This test was done for testing the QML graphic elements of the game canvas which included testing of all the animation timings, updating of state variables at proper times (right after an animation finishes or before it begins), the moving back of the cards played and destroying them a second after the fourth card is played at each trick, updating the scores after the cards are destroyed, placing the horizontal and vertical cards and spacing them correctly showing a won or lost trick, spacing the cards in the card holder correctly, changing the design of the card deck when asked for, loading proper card images when requested etc. While testing this particular part of the game, all the animations were carefully " mapped with the associated state variables to be updated and then implemented according to the update. This test concluded that while a declarative language can be very easy to use for graphics and animations, it is a little cumbersome to take care of the complex data associated with the various graphic components, particularly Javascript state variables.

Client Server Interaction: This test was done for testing the Server and Talker modules. The chosen Client Server architecture is designed to forward each client move to 3 other clients on the same table. So it is very crucial that moves are not sent across tables, which would create a lot of confusion and breakage in the tournament as well as the software. Moreover, the clients do no validation of the incoming moves because every outgoing move is strictly validated before being sent. So it is very important that the server does not mess up with the sequence and destination of the messages. Hence this test included testing of maintenance and arrangement of client sockets inside the server application. It is necessary to map every client socket with the table they are playing on and the player they are playing as, so as top interpret correct source and destination of the messages. The server maintains a list of authenticated clients and so it is important on the client's part to not lose connection with the server. TCP helps in maintaining a reliable stay-alive connection.

(v) Server's Tournament Management: This test involves testing of the MovementModel module of the server application. The tests included sending of correct cards to the players at various -tables, maintaining the seating arrangement, updating it after each round, placing the. incoming scores from different tables in proper sequence and boards, registering the scores with proper score sheets, notifying the players of their seating arrangement for the next round and computing the final rankings of the participating partnerships at the end of the tournament. Problems found in the Howell movement were fixed by hard-coring the movement tables in the implementation.

(vi) Tournament Logs: In this part, the Logger and the Replayer module of the server application were tested. It involved verifying that the logs are stored in correct format and can later be retrieved for review purposes. Since this mostly uses Qt's internal QtXML module, it didn't have any major errors. The crucial part of the Logger module is the importing of previous logs and correctly showing the retrieved data on the server interface and feeding the data to the replayer if the user wants to replay a match.

The present invention is highly advantageous as it provides a system and method for playing contract bridge game without using playing cards and associated paraphernalia. Due to this method, various nuisances of the prevailing method of playing the game like invalid moves going unnoticed, complicated scoring scheme, errors in calculation of results, cheating by the players, errors occurring while moving the boards, players, score sheets, pair numbers etc., manual preparation of boards and charts, proper storage of paraphernalia, disturbance due to spectators etc. are diminished.

The present invention allows playing the contract bridge game with the following features:

• Complete tournament can be played using computers on a network.

• The product can be installed on any desktop operating system.

• Players can bid, play their cards and see their score on their screen.

• Spectators can join in on any table during a tournament to view the on-going match.

• Players can toggle the option to confirm before making the desired move.

• Four deck of cards are provided for every player to choose from with three different designs.

• The players need not specify the server's IP address as the client implements an automated server discovery mechanism.

• The application supports Mitchell movements for upto 50 tables and Howell movements for upto 20 tables.

• It supports Matchpoints and IMP (International Match Points) tournament scoring.

• Old tournaments can be reviewed and matches be replayed. They can also be exported to portable files.

Although the preferred embodiment as well as the construction and use have been specifically described, it should be understood that variations in the preferred embodiment could be achieved by a person skilled in the art without departing from the spirit of the invention. The invention has been described with reference to specific embodiment which is merely illustrative and not intended to limit the scope of the invention as defined in the claims.




 
Previous Patent: VIRAL TRAPPERS

Next Patent: AMORPHOUS VILDAGLIPTIN