Objective

For a developer with limited know-how of web technologies, the task of designing and deploying an online multiplayer game is fraught with challenges. There are many off-the-shelf technologies to assist her but it is precisely this plethora of choices that become a handicap. Here we try to document the development process so that the choices made along the way and the design issues are made as clear as possible to anyone who wishes to develop their own Online Multiplayer Games.

What are we trying to develop?

We want to develop an online card game called 56 and deploy it on the internet. We do not have our own servers so we need to rely on some of the free services available. In the next few paragraphs, we address the following issues;

1. What will the end product look like? What is the typical user experience like?

To play this game, the user first needs to authenticate. We will allow only authenticated users. Once logged in, the player reaches an arena and can interact with other players. A group of 6 players can initiate a game. Since there are multiple players, a conflict resolution mechanism has to be in place to address any issue that may arise in the course of the game. One way to address this is to select/elect a leader.

The game we want to develop is a turn-based game. Once the game begins, the players carry out their moves based on their turn and based on an end game criteria the game finishes. This process gets repeated again and again. The data corresponding to each played game is stored and the players can retrieve game data and run various statistical analysis on the game data.

2. What is the mental model of our software?

There are three main components for this software each accomplishing a particular task;

   2.1 The user interface or the browser side software.

This component accomplishes the task of delivering the content to the user. Based on the state, which encapsulates all the relevant information for a player (like login, game state, players involved etc) the browser side software delivers the appropriate content to the end-user.

   2.2 The database

Each user generates data while playing. This information will be stored in a database and will be provided to the users based on their various requests via the browser.

   2.3 The back end or the server-side software 

This component takes care of all the requests that are generated by the browser. These requests could include

       + Requests to update the game configuration based on the user's move

       + Request to  ascertain the  completion of the game

       + Request to store information for later use

• Request to retrieve past information

• Authentication of players

• Registration of players

More on the specific game

(It is okay if you skip this section. The only thing you need to know is that there is a bidding phase and a playing phase. At the bidding phase, some decisions are made about the gameplay. During the playing phase, the game is played according to these decisions. The game finishes after a fixed number of moves and a winner is declared)

The game we plan to develop is the game of 56. The game has many intricacies. We won't bother about this in our initial stage. Instead, we initially develop a skeletal game and modify it later. The rules of the skeletal game are as follows.

1. Each player gets 8 cards from a 48 card deck

2. There is one round of bidding. The highest bidder can choose the bid value and the trump.

3. The starting player plays a card and other follow suit. Highest card wins the trick and gets the turn to play the next card. If the suit played is unavailable, the player can ruff with the trump.

Developing the Game

Browser side

Here we shall provide the details and mention the technologies we used to solve the issues at hand. First, let us look at the browser-side code.

We need to accomplish the following via browser-side code

1. The user interface for authenticating

2. Game Arena for authenticated players

3. Playing Board for a group of players with the possible additional option of viewers The Playing board takes care of the following

   3.1 Receiving the player moves and communicates it to the server and updates the state.

   3.2 Checks for game completions

4. The game statistics

Server Side

For all the requests generated from the browser side, the server must be written to take care of all those requests appropriately.

Database

As such we may not have much coding here as once the tables are set up properly, the server-side code basically accesses the database as per the various requests it receives.

Design challenges

1. Where is the game data stored during the game? In the database or in the server-side code?
2. Try and design in such a manner that if the "variables" are set in config file, anyone can deploy a new website for playing with a single command.

The Game Server

The Game server is a program which runs on the "server" (the computer which hosts the game app). Its job is to store a representation of the game and keep updating it as the game progresses. We will use the boardgame.io framework to do this task. One may view this as follows. There is a game object that the server stores. Each move from the players' updates this object.

Game Definition - boardgame.io's Game Object Setup Moves, Turns and Phases Gameplay

We describe the game object in the below paragraph.

Set Up (Stores the information at the start of the game

The set up stores the following information

Hand of each player

Starting Player

Points up till now

Moves, Turns and Phases

Phase indicates if the phase of the game is the bidding phase or the playing phase. Further if it is the bidding phase the last_player_bid variable indicates the last player who has made a bid. An array stores all the previous bids starting from the first player

In the playing phase the following information is kept.

1. Number of tricks played.
2. Hands of individual players after their plays
3. Next player to play.

After every trick, the next player is suitably altered. After 8 tricks the playing phase is ended and a winner is declared. In every turn the player can select one of her cards to play. Sanity check required if ensure that a player doesn't play out of turn.

The components include:

a. Server

• Database

  • User, where each user has the following attributes

    • Username, Password Hash
    • Games they have played
    • Some rating/ranking maybe
    • Current Game

  • Games, where each game has the following attributes

    • Game ID
    • Players Involved
    • Game type
    • Move History in the appropriate format

• Game Server monitoring each running game

  • This can be the existing boardgame.io's Lobby object.

b. Gameplay - Each game on the server has gameplay which has two components

• Game Definition - boardgame.io's Game Object

  • Setup
  • Moves, Turns and Phases
  • Gameplay

• Board Definition - boardgame.io's Board Object

  • How the board looks - UI
  • How the user interacts - UX

c. UI

• UI of the lobby/authentication/profile page

• UI of the game - stored in 'Board' definition.

UML Diagram

The Game of 56

1. Overview

This is a trick-taking+point based game. The game is played by either 6 or 8 players grouped two partnerships. The game is played in two stages. The first stage is a "bidding stage" where the partnerships bid competitively. The second stage is the "play stage" where the cards will be played out. The objective of each partnership is either to win a bid and then deliver on the bid made or to stop the opponent from delivering on the bid they made.

1.1 Bidding Stage

The highest bid determines the contract to be played for. The winning bidders partnership will be called the "proposing partnership" and the other partnership will be called the opposing partnership.

1.2 Playing Stage

The lead player plays a card and the others are supposed to follow suit in a clock wise manner. The player who plays the "highest" card wins the trick/round for the partnership and also gets the opportunity to be the lead player for the next round. After all the tricks have been played out the total "points" from all the tricks won is computed. If the bidding team has scored the number of points equal or more than their bid, they will be declared winners. And the process continues.

2. Details

2.1 Card Deck

The description here focuses on the 6 player version of the game. The game is played with a subset of the cards from two standard 52 deck cards. The allowed pips are A,9,10,J,Q,K of every suit. Thus the total cards is play is 6x4x2. (Additionally, the pips 7 and 8 can be added when there are 8 players) After shuffling, each player gets 8 cards. The value of each card is as follows;

• J 3 point
• 9 2 point
• A 1 point
• 10 1 point
• K 0 point
• Q 0 point

The cards are ordered as J>9>A>10>K>Q. Clearly this ordering is consistent with the points as well. The total points of all the 48 cards together is 7x4x2=56 and that is the name of the game. Crudely put, the objective of each partnership is to bid and win the maximum possible points with the hands they have.

2.2 The Notion of Trump Suit and Ruffing

During the bidding stage, the bid establishes one of the suits as trump ( or declares that there wont be any trump). Once the bidding is over and the game has entered the playing stage, the player on the right of the dealer opens with a card of his/her choice. Others are expected to follow suit if they are in possession of cards from that suit. If they do not have the same suit they can put any card of their choice. This is called ruffing.

2.3 The Bidding stage

The player on the right of the dealer starts bidding. This will also be the player to lead the first trick. The bidding progresses till all players agree on the bid. The following terms are the only allowable in bidding

• A number followed by a suit. eg. 28 Heart
• A suit followed by a number. eg. Hearts 35
• Plus followed by a number followed by a suit eg. Plus 2 hearts
• A number followed by no trump. eg. 30 NT
• A number followed by NS eg. 36NS
• Pass, Double, Redouble

2.3.1 Additional rules

• The first bid cannot be a pass.
• The existing bid must be a double (ignoring the pass bids) for a redouble to be bid.
• There are no bids after a redouble.

The bids of type 1 and 2 fixes as trump suit the suit indicated in the bid. The bids of type 3 and 4 fixes that there will not be any trump. The type 5 bid doesn't change the trump. Whatever was the trump fixed by before his/her bid remains in force. In bids of type 1,2,4 and 5, the value of the bid is the number indicated. In the bid of type 3, the value is the value of the previous bid incremented appropriately. In bid 6 the value remains unchanged.

The bidding process begins with value 28 and continues till all the players pass or the value 56 is reached. Every bid except type 6 bids must increment the value of the bid. When the bid process ends, an agreement on value and trump suit is reached. The partnership with the winning bid is supposed to reach at least the bid value using the trump established at the winning bid.

2.4 Contract Points

The contract points for winning the game is as follows

Bid Value	Bidding Team Wins	Bidding Team Loses
28-39	1	2
40-47	2	3
48-55	3	4
56	4	5

The contract points are doubled and redoubled if the bids were such.

Eg. If team A bids 48 Hearts and loses, Team B gets 4 contract points. If there was a double then Team B gets 8 points.

2.4 Playing Stage

After the 6 player have played their cards, the winner of the trick is decided based on the following rule;

• If there are no trumps played, the highest card played in the lead players suit is considered the winner.
• If there are one or more trumps played, the highest card played in trump suit is considered the winner irrespective of the opening suit.

The winner of the trick gets to be the lead player for the next trick. After all the 8 tricks have been played out, the points in the tricks won by the partnerships are tallied to see if they have honoured their bid.

Notes/ Future Features

• Ideally, there should be an option for turning on anonymous play for each game.
• Old games can be used to create new/interesting games

How do the different functions/objects/files/components connect with each other?

Files and folders of src/

Folder containing the main code of the Application

- games/ - Folder containing game and board definition

- App.css - Style sheet for app

- App.js - Main App Container

App.test.js - File to write tests in for App.js

index.css - Styling index.html

index.js - JS for rendering App.js in index.html

logo.svg - Favicon file

server_dev.js - Development Server File

server.js - Deployement Server File

serviceWorker.js - File if you want offline functionality

setupTest.js -Dom testing library