CHAPTER IV

GAME DESIGN

4.1. Game Overview

The Trash Online is a game that adds multiplayer capability to the classic

Tetris game. In this game, players will be able to interact each other and play

against each other in the modes provided. This game will show that a simple

and well-known Tetris game could be made into something new and fresh with

just adding some features without changing the basic gameplay.

4.2. Game Features

The followings are the features that will be implemented in the game:

• Login and Logout capability

Each player will have a unique character that is protected with a password.

The game will be able to send the character's username and password to

the server and match it with the data on the database. If the name and

password is a match, the player can start playing the game.

32

• Game Lobby

Game lobby is the where all connected players are gathered before the join

a game room. Here they can chat with other players, join an available

game room shown on the game room list, or create a game room with

modifiable parameters.

• Game Room

Game room is like a waiting room for the players before the game is

started. Here they can chat with each other or leave the room before the

game is started. The owner of the room can change the parameters of the

room, kick other players or start the game if all other players are in ready

state. To be in a ready state, the player must click the ready button.

• In Game

In game is a state where the player is playing the Tetris game and

competing with each other until a winner is declared. The players can still

chat or leave the room if they wished to do so.

• Scoreboard

A score board is a pop up screen that will appear after the game is finished.

The scoreboard will show the results and statistics of the game. The

scoreboard will appear in a range of time before the players are redirected

back to the game room to wait for another game.

33

4.3. Use Case Diagram and Narrative

The following is the use case diagram of the game.

Figure 4.1. Use Case Diagram.

34

Use Case Name Login.Actor Players.Description Send Username and Password for validation.Trigger Players click “Login” button.Post Condition Send data to server for validation. If authorized, show

game lobby.

Table 4.1. Use Case Narrative: Login.

Use Case Name Chat.Actor Players.Description Send chat content to server for broadcasting.Trigger Players press enter on chat box or press the “submit chat”

button.Post Condition Send data to server for broadcasting.

Table 4.2. Use Case Narrative: Chat.

Use Case Name View Player List.Actor Players.Description Display player list.Trigger A player join the game lobby.Post Condition Player list displayed.

Table 4.3. Use Case Narrative: View Player List.

Use Case Name View Game Room List.Actor Players.Description Display game room listTrigger A game room is created.Post Condition Game room list displayed.

Table 4.4. Use Case Narrative: View Game Room List.

35

Use Case Name Join Room.Actor Players.Description Join a game room.Trigger “Game room list” button clicked.Post Condition Send the request to server. If authorized, show game room

and update the game room.

Table 4.5. Use Case Narrative: Join Room.

Use Case Name Create Room.Actor Players.Description Create a new game room.Trigger “Create game room” button clicked.Post Condition Show “create game room” pop up page. Send the request

to server. If authorized, show game room and update the

game room list.

Table 4.6. Use Case Narrative: Create Room.

Use Case Name View Player Info.Actor Players.Description Display player's info.Trigger “View player info” button clicked.Post Condition Display player info pop up page.

Table 4.7. Use Case Narrative: View Player Info.

36

Use Case Name Change Room Parameter.Actor Players.Description Change the game modes.Trigger The room creator / owner clicked the mode modifier arrow

button.Post Condition The game mode is changed.

Table 4.8. Use Case Narrative: Change Room Parameter.

Use Case Name Play TetrisActor Players.Description Play Tetris game.Trigger The game is started.Post Condition Tetris gameplay started.

Table 4.9. Use Case Narrative: Play Tetris.

Use Case Name View Scoreboard.Actor Players.Description Display scoreboard.Trigger Game over or victory condition achieved.Post Condition Scoreboard displayed.

Table 4.10. Use Case Narrative: View Scoreboard.

37

4.4. Activity Diagram

Here is the activity diagram.

Figure 4.2. Activity Diagram: Login.

Figure 4.3. Activity Diagram: Chat.

38

Figure 4.4. Activity Diagram: Join Room.

Figure 4.5. Activity Diagram: Create Room.

39

Figure 4.6. Activity Diagram: View Player Info.

Figure 4.7. Activity Diagram: Change Room Parameters.

40

Figure 4.8. Activity Diagram: Play Tetris.

41

4.5. Screen Flow Chart

Here is the flow chart of the screen.

Figure 4.9. Screen Flow Chart.

4.6. Tetris Guideline, Gameplay and Mechanics

4.6.1. Tetris Guideline

Tetris Guideline is the specification that the Tetris Company provide for

all tetris game products development. The guideline is intended so that

42

all Tetris games have a similar rule. Here is the rules that will be

implemented in the game:

• The playing field is 10 cells wide and at least 22 cells tall, where rows

above 20 are hidden or obstructed by the field frame

• Start Location of tetrominoes:

- The I and O spawn in the middle columns

- The rest spawn in the left-middle columns

- The tetrominoes spawn horizontally and with their flat side

pointed down.

• Super Rotation System specifies tetromino rotation. SRS represents

where and how tetrominoes spawn, how they rotate, and what wall-

kicks they may perform. A wall kick is a situation when a player

rotates a piece when no space available in the tetromino would

normally occupy after the rotation.

• The tetrominoes are spawned randomly.

• Game must include a song called Korobeiniki.

• The player lost the game when a piece is spawned overlapping at least

one block, or a piece locks completely above the visible portion of the

playfield.

43

4.6.2. Gameplay

During the game, the players compete with each other by staying alive

until the end of the game (Deathmatch Mode), by earning the highest

score with the time limit (Time Attack Mode) or by earning a certain

amount of score before other player (Point Break Mode). On each row

clearance, the players will gain a growth on their attack bar and when the

attack bar is full, the players will have a random chance to attack random

players.

4.6.3. Game Mechanics

Here is the game mechanics that are not included in the Tetris Guideline.

• The number of players in a game ranged from 2 to 8 players.

• The game cannot be started by the owner until all the players are in

ready state.

• The owner of the room can kick other players on the room.

• In the Deathmatch Mode, the victory condition is when there is a

single survivor.

• In the Time Attack Mode, the victory condition is when the time is

over and the winner is the player with the highest score.

44

• In Point Break Mode, the victory condition is when a player reached

an amount of score before others.

• After a row clearance, the player will get an amount of score.

• After a row clearance, the player will grow the attack bar, when the

attack bar is full, the player will have a random chance to attack

random players.

• After a row clearance, the player will gain score.

• The speed of the game will be increased over time.

• After each game the player will receive experience, and game money.

• When the the player's experience reach a certain amount, the player's

level will be increased.

4.7. Scoring System

The following graph shows the score the player will get after clearing a row.

As the difficulty to get more rows cleared consecutively, the score gained will

also increases.

Score gained = ( number of rows cleared consecutively * 100 points +

( number of rows cleared consecutively ) 2 * 50 ) * ( 1 + ( game speed –

1 ) / 10 ) )

45

Figure 4.10. Score Graph.

The following graph shows the amount of experience needed to gain a level.

The experience is cumulative, so every time the a player gain a level, the

experience total will not be reset to 0, it will just add more experience instead.

Experience Need = Total Experience + Current Level * 500 * 1.3

Figure 4.11. Experience Need Graph.

46

1 2 3 4 5 6 7 8 9 100

1000

2000

3000

4000

5000

6000

score

1 2 3 4 5 6 7 8 9 100

5000

10000

15000

20000

25000

30000

35000

40000

45000

score

The following graph shows the amount of experience that will be distributed.

The distribution depends on the total player on the game and the winning

position.

Experience = Total Player * 25 / Winning Position

Figure 4.12. Experience Gained Graph.

4.8. Game Engine

The game will use the following game engines.

• Irrlicht version 1.6.

• IrrKlang version 1.3.

• RakNet version 3.

47

1 2 3 4 5 6 7 80

50

100

150

200

250

experience

4.9. Game Architecture

The game will be divided into 2 applications, client application and server

application. When the user of the client application do something that can

affect the other player, the application will send a request to the server to reply

with an authorization.

Figure 4.13 Client-Server Data Flow.

The client application will implement the Model–View–Controller (MVC)

architecture model. The following figure is the MVC model of the client.

Figure 4.14. Model–View–Controller (MVC) Architecture Model.

48

The followings are the details of the processes inside 'Model'. All classes use

“TO” prefix.

Figure 4.15. Model Process.

TOStateManager is the class that deals with the game states. The class

manages with the change of the game state and give the information of the

current game state to other classes.

TOPacketHandler is the class that deals with creating, sending and receiving

packets. The detail of this class can be found in a related work by Ryan

Sutedjo.

49

TOGUI is the class that deals with loading GUI assets and how the system will

display the GUI, TOGame is the class that deals with the gameplay. The detail

of this class can be found in a related work by Ryan Sutedjo.

The following is the detail of the processes inside 'View'. Since Irrlicht provide

a function to display everything, the view action is simply to provide irrlicht

with the data which needed to be displayed and which is not.

Figure 4.16. View Process.

The following is the detail of the processes inside 'Controller'. The methods for

controller is also provided by Irrlicht, TOInputHanlder is just the

implementation of the methods.

Figure 4.17. Controller Process.

50

TOInputHandler class handles the user input. It constantly related to

TOStateManager as the user input is very sensitive to game state changes.

The followings are the design of the classes in form of a class diagram.

Figure 4.18. Class Diagram.

51

Figure 4.19. TOGUI and TOGame Class Detail.

52