-
Notifications
You must be signed in to change notification settings - Fork 0
Developing an Online Multiplayer Game
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.
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;
- 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.
- 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
(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.
-
Each player gets 8 cards from a 48 card deck
-
There is one round of bidding. The highest bidder can choose the bid value and the trump.
-
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.
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
-
The user interface for authenticating
-
Game Arena for authenticated players
-
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
-
The game statistics
For all the requests generated from the browser side, the server must be written to take care of all those requests appropriately.
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.
- Where is the game data stored during the game? In the database or in the server-side code?
- 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 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.
The set up stores the following information
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.
- Number of tricks played.
- Hands of individual players after their plays
- 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.