Design of Networked Multiplayer Snake and Ladder Educational Game Based on Hash Map and Vector Data Structure

Computer games have been used as educational media or popularly named as educational games. However, most educational computer games that have been created can be played by one player. This study aims to build a multiplayer ladder and snake educational game. The game is built on Java socket programming and local area network (LAN) as a data communication medium between players. Whereas to handle the username and socket address of the whole player, the hash map data structure is used. A vector data structure is also used to manage data package sending for each player group. The experiment shows that the system works properly where the computer server’s performance is influenced by the specifications, especially the processor and random-access memory (RAM).


I. INTRODUCTION
Nowadays, computer games have been used in education, from elementary school to college. Several studies on the development of computer games for education, for instance, games for natural science courses [1], health education [2], mathematics education [3], [4], physics learning [5], learning English [6], teaching computer programming [7], [8], math logic [9], introduction of rare animals [10], educational game on waste handling [11], and five senses learning [12] has been conducted. It was concluded that the use of computer games in education showed positive results, namely increasing student interest in learning and making it easier for students to understand the learning material. However, the game from this study can be played by one player (singleplayer). The research showed that games played more than one player (multiplayer) were more challenging than singleplayer [13]. Besides, school-age children tend to like competition games and are played in groups [14].
Many multiplayer games have been conducted, battleships [15], for example. In this game, two players are connected in a peer to peer network with a cross cable, where one computer player as a server and the other as a client. However, the number of players is limited in this game, which is two players. Another multiplayer game is the snake and ladder game [16]. More than two players could play this multiplayer game; although, there is no player grouping feature (group); thus, the number of players in the game is potentially too much. The next multiplayer game is truf [17], which has a player group creation feature, although the group must wait until the fulfillment of four players. Another multiplayer game is gobak sodor [18], which is built based on flash, whereas there are still bugs, one of them when used to play more than two players, there will be a lag or stop. There are also spirit card multiplayer games [19], which can be played by six players; nevertheless, there is no group feature yet. Thus, the game system is limited to handle six players.
This paper aims to design and implement in build multiplayer snake and ladder educational games with arithmetic learning content. The game was built on Java Socket Programming and used a Local Area Network (LAN) to communicate between players. The game was designed for players to create groups or join existing groups, where each group consists of four players maximum.

II. METHOD
The game's main interface for the player is a snake and ladder graphics board composed of 100 small squares with ten vertical squares by ten horizontal squares. This board is equipped with images of snakes and ladders at particular square locations. Players use the board to play the game. On the right side of the board, a username is included as the players' identity in a group.
Underneath the player's identity is a dice visualization and a shuffle button to determine the number of steps the player has when taking a turn. For educational content, arithmetic questions are included. Questions would appear when a player stops at the snake's tail or ladder's base square. If the player succeeds in answering questions, the player does not go down to the square following the snake's body or go up to the square following the stairs, and vice versa. The main interface mockup of the game, as shown in Fig. 1.
Based on research about programmable network architecture has been conducted [20]; therefore, a distributed system is applied to the game with a clientserver architecture model [21]. The server is a computer that serves the client, while the client is a player's computer that obtains service access to the server. In this system, the server works actively to process data packages from player groups or requests from clients. In general, the data package flow processes on the clientserver consist of client-server connection, input data on the client, client-side data processing, server-side data processing, and broadcasting, as shown in Fig. 2. Each step will be discussed further in the next subsection.

A. Client-server Connection
The game can be played by two to four players in each group as clients (Fig. 3). In Fig. 3 to simplify, two-player groups are used; however, the system could accept more than two groups. The first process in constructs a network is starting with the server opens a connection and waiting for the client to join. The server opens a specified port. A server socket is formed on the server application side and listen/waiting operations for connection requests from the client-side.
On the other hand, the client requests the IP and port that has been opened by the server. When the client connection request arrives at the server, the server will create a socket. This socket will be used to communicate with the socket on the client-side. Then the socket server does listen more to wait for connection requests from other clients. Games are designed to handle multiple players at the same time by implementing multithreading. Thus, the server can hold the connection process of several players at once.

B. Input Data on The Client
A player that has been connected server, then enter a username that is used during play the game. Username is the identity for each player. After a username is entered, the player can create a group or join groups that have been created by other players. Then sends the data containing the username, socket address, and group name to the server. The server receives and stores it in the HashMap with the structure: HashMap(string, socket). The string is variable containing the username, and the socket is a variable for storing the player's socket address. Then the server saves the username and group name into the database. Username and group name is used to identify players who are members of the group in sending data to other players through the server. Table I shows the database design used in this game.
The database game consists of one table that contains three fields, namely username, group, and ket. Each field has the following function: username for storing the player username, group for the name of the group that the player follows, and ket for player or group information. The username is the primary key of the table to make it easier to find and manage the player's socket on the HashMap.

C. Client-side Data Processing
Before the game starts, the player can join an existing group or wait for other players to join the created group. After all players in a group are ready, the game can be started. While the game is in progress, each player sends a data package containing its position on the game board to the server to be broadcasted to other players in the same group. When the player gets turn to play, then shuffles the dice. The dice's number as a reference on how many squares must player walk through the game board. In this process then the player's computer (client) sends its position data to the server in a string data packet format as follow: <nama_grup>:<username>:<posisi_saat_ini>:<posisi_s ebelumnya> Where <nama_grup> is the name of the group the player is following, <username> is the name of the player who is playing, <posisi_saat_ini> is the last player's position on the square board, and the <posisi_sebelumnya> is the position before shuffling the dice. The ":" character is a delimiter used to split string to be processed separately. For example, GrupX:Budi:17:15, can be explained as follows: GrupX is the group's name, Budi is the username of the player, 17 is the last position of the Budi, and 15 is the previous position. Flowchart sending data from client to server is shown in Fig. 4.
Besides sending data to the server, the player also receives data from the server when other players in the same group get their turn to play. Data packages received by a player are split to get other player position data. Fig.  5 shows the player receiving data from other players through the server until the visualization of its position on the snake and ladder game board. Data packet splitting is done with a split function in Java based on delimiter characters (:). The data package is split into four parts: <nama_group>, <username>, <posisi_saat_ini>, <posisi_sebelumnya>. Then this data is stored in an array as follows: [username], [posisi_saat_ini], [posisi_sebelumnya]}. To get the player's position from the array can be accessed using the index, for example: userNm = arraydata [1], posSkrg = arraydata [2], and posSblm = arraydata [3]. After getting another player's position, the player game program visualizes it on the snake and ladder game board.

D. Server-side Data Processing and Broadcasting
Besides, as a data broadcaster to the player, the server also processes data. When the server receives a data packet from the player, the server processes and splits it to find out the player's group name. The data processing by the server is shown in Fig. 6. Same as in the client, the server splits data package with split functions in Java with a delimiter (: Thus, the name of the player can be obtained from index 1 of the array data. Next, the server takes the name of the player group from the database. Then look for all player names with the same group name in the database. After the player's name is known, the server checks on HashMap whether the player with the name is valid. After that, based on the player's name, the player socket address is retrieved from HashMap and collected in a vector. Last, the data packet is sent to clients (players) through the socket address that has been stored in the vector. Thus, the server broadcasts the data packet to all members of the group.

III. RESULTS AND DISCUSSIONS
In this section, the results of research and examination of game software will be discussed, including experiment client software that displays an animated snake and ladder board with interactive graphics during the game and server software as moderator the player group during the game running.

A. Player's Game User Interface
This study's output is an educational ladder and snake game which is played together in a network, where players are collected in groups. The game interface for a player (client-side) is shown in Fig. 7. The game interface is an interactive graphical display that is used to play the game. It is a snake and ladder game's board consisting of the player's pawns, player's identity, live chat feature, and dice with the shuffle button. The arithmetic quiz questions would appear when the player stops at a square with a picture of a ladder base or snake tail.
Rules of the game as in a game of snakes and ladders in general, which players compete to reach the top square with number 100, starts from the bottom square with number 1 according to the appearance of dice numbers shuffled when one player gets a turn to play. The player shuffles the dice with the shuffle button with the text "turn."

Fig. 7 Game user interface for player
When the player's pawn stops right at the square, which is the base of the ladder image, the player has to open the questions; hence interactive graphics of the quiz would appear. Players are allowed to answer questions for 10 seconds. If the answer is correct, the player's pawn will go up to the square where the ladder's end is. Otherwise, the player's pawn fails to go up. Likewise, if in 10 seconds the player does not answer, it is considered wrong, and the player's pawn fails to rise. Whereas when the player's pawn stops at the end of the snake's tail, the player has to open a quiz question yet with different rules. If the answer given by the player is correct, then the player's pawn does not go down to the square where the snake's head is. Otherwise, if the player's answer is wrong or the question is not answered within 10 seconds, the player's pawn will go down to the piece where the snake's head is.
The game also features a live chat feature for more excitement. Players who are members of the player group could see the text of conversations sent by other players. The player also could send a message by typing it in the text field then click the OK button; thus, the message appears in the text area and can be seen by all player group members.

B. Server User Interface
The server is a computer as a moderator to manage and control player activities. The appearance of the server program interface is, as shown in Fig. 8. There is an ON / OFF button in the server program interface to enable or disable the server, whereas the text area is used to monitor ongoing activities. Before the game can be played, this server must be active.

C. Login User Interface
The login interface is in the player (client-side) game program. Fig. 9 shows the login interface intended. In the login interface, three text fields must be filled by the player: host or server IP, the same port used by the server, and the username as the player's identity in the game group. Before playing, players must log in to connect to the server, and then they could choose or create a new player group.

D. Player Group List User Interface
The list of player groups that have been created is displayed in the player group list interface that appears after the player has logged in. The group list interface is shown in Fig. 10. If the player wants to create a new player group, it can be done by clicking the "Create Group" button.
There is a "refresh" button in the player group list interface to update the player group list created by other players. If the player wants to join an available group, it can be done by clicking on the group name that appears in the group list. When the player selects the intended group of players, a confirmation dialog will appear, as shown in Fig. 11. In this interface, there is also a "help" button to display playing instructions, an "about" button to display program information, and an "exit" button to stop and exit the program.

E. Create a New Group User Interface
In the interface for creating a new group, players could create a new player group by entering the group name in the text field. The interface is shown in Fig. 12.

F. The User Interface of The Group's Player List
The player list in a group is displayed in the group's player list interface, as shown in Fig. 13. The names of the players are displayed in text area. There is also a "play" button to start the game.

G. Player (Client-side) Program Examination
The program is examined by the black-box method to determine its execution and function in the client (player) and server program working as they should. The program was run to analyze the algorithms and functions. The examination is valid if the result is the same as expected. The results obtained are presented in Table II. These results indicate that both client and server programs run properly.

H. Server Performance Examination as a Player Group
Moderator Server performance is examined to determine the server to manage the player's data, players, and player groups successfully. The experiment results are used to analyze server capability to manage players in several groups and their data traffic without missing or unsent data.
Experiments are conducted by observing and analyzing client requests data from server and broadcast data trough server to several players in the right group. In one experiment session, one server is used with six group players, where the first and second groups consisted of two players, the third and fourth groups, consisted of three players, and the fifth and sixth groups consisted of four players.  The login data player appears on the server monitor Valid The server closed the connection All saved data is deleted Valid Player login (Data entered is incomplete) The system will not save the player data and the notification "Data not complete yet" The server has different specifications, where the computer and its specifications are presented in Table III. The player (client-side) computer was not specified. However, a computer with 2 GB of RAM is used. From experiments could be obtained data presented in Fig. 14.
Based on the examination, varied results were obtained. When the first server was used in the experiment, there are many data packages not sent to the player (client), as shown in Figure 14(a). Similarly, with the second server, some data packages were not received by several clients, as shown in Figure 14(b). The first and second servers have the same processor specifications, although the second has the bigger RAM. However, it has not a significant impact on data package transmission.

Fig. 14 Server examination result
When the higher specification server is used, the results are better than the previous experiments that the unsent data package could be reduced, as shown in Figure 14(c). The last experiment using the highest server specification is intended to decrease the failure of sending a data package that has the best results, as shown in Figure 14(d). There are two of 18 players (clients) who were not sent the data package.
Overall experiments show that unsent data packages often occur when it received by the first player. From white-box observations of data entering and leaving the server, it indicates that this is due to the initial data package sent by the first player that could not be received and processed on the first computer's player.
Experiments showing there is also an incomplete packet data received by the client. This occurrence is due to the processing of data packages on the client or server, which corrupts the data; thus, the data package is incomplete. Data corruption could affect the next data packages send and receive. However, this rarely happens to the system.
Although there were several data package sending failures, the examination results generally showed the server's success as a moderator of the player group. From the experiment, it was shown that none of the data packages were sent to other groups. The data package was successfully sent to the players who are in a group of sending players. Based on the experiment data, the percentage of success in sending data can be measured with Eq. (1). From Eq. (1), the experiment results are the first, and the second server shows the success of sending data rate is 77.70%, whereas the third is obtained 83.30%, and the fourth with the result 88.80% as shown in the graph in Fig. 15. Fig. 15 The success rate of the server sending data IV. CONCLUSION Based on the discussion and examination results, it can be concluded that the moderator system in the educational multiplayer snake and ladder game works successfully. Experiment with a server with different specifications shows different results; the first and second servers achieved a 77.7% rate of success in sending data. The third showed 83.3%, and the fourth reached 88.8%. This server's performance is influenced by computer specifications, especially the combination of the processor and RAM, where the higher the computer specifications, the higher the success rate of sending game players data.