PENGEMBANGAN LOCAL AREA NETWORK GAME SERVER UNTUK MULTIPLAYER TANK GAME MENGGUNAKAN TEKNOLOGI JAVA SKRIPSI

PENGEMBANGAN LOCAL AREA NETWORK GAME SERVER UNTUK MULTIPLAYER TANK GAME MENGGUNAKAN TEKNOLOGI JAVA

SKRIPSI Diajukan untuk memenuhi sebagian persyaratan Memperoleh gelar Sarjana Teknik

Disusun Oleh: ERIQ MUHAMMAD ADAMS J. NIM. 0310630043

DEPARTEMEN PENDIDIKAN NASIONAL UNIVERSITAS BRAWIJAYA FAKULTAS TEKNIK MALANG 2009

PENGEMBANGAN LOCAL AREA NETWORK GAME SERVER UNTUK MULTIPLAYER TANK GAME MENGGUNAKAN TEKNOLOGI JAVA SKRIPSI Diajukan untuk memenuhi sebagian persyaratan Memperoleh gelar Sarjana Teknik

Disusun oleh: ERIQ MUHAMMAD ADAMS J. NIM. 0310630043

DOSEN PEMBIMBING:

Suprapto, ST., M.T.

Ir. Muhammad Aswin, MT.

NIP. 132 149 320

NIP. 131 879 045

Kupersembahkan karya ini untuk Allah SWT & Rasulullah S.A.W. Ayahanda & Ibunda Tercinta

PENGANTAR Dengan nama Allah SWT Yang Maha Pengasih dan Penyayang. Segala puji bagi Allah SWT karena atas rahmat dan hidayahNya-lah penulis dapat menyelesaikan Tugas Akhir yag berjudul “Pengembangan Local Area Network Game Server untuk Multiplayer Tank Game Menggunakan Teknologi Java”. Shalawat dan salam atas junjungan besar kita Nabi Muhammad S.A.W. beserta keluarga dan para sahabat sekalian. Tugas Akhir ini disusun untuk memenuhi sebagian persyaratan memperoleh gelar Sarjana Teknik di Jurusan Teknik Elektro Program Studi Teknik Informatika dan Komputer Fakultas Teknik Universitas Brawijaya Malang. Melalui kesempatan ini, penulis ingin menyampaikan rasa hormat dan terima kasih penulis yang sebesar-besarnya kepada semua pihak yang telah memberikan bantuan bantuan baik lahir maupun batin selama penulisan tugas akhir ini. Oleh karena itu, pada kesempatan ini penulis ingin menyampaikan rasa hormat dan terima kasih penulis kepada : 1. Kedua Orang Tua penulis (M. Sholehan Yusuf dan Mufidah) dan seluruh keluarga yang senantiasa tiada henti hentinya memberikan do’a demi terselesainya tugas akhir ini. 2. Bapak Ir. Heru Nurwarsito, M.Kom dan Bapak Rudy Yuwono, ST., M.Sc. selaku Ketua dan Sekretaris Jurusan Teknik Elektro serta segenap Bapak/Ibu Dosen, Staff Administrasi dan Perpustakaan Jurusan Teknik Elektro Fakultas Teknik Universitas Brawijaya. 3. Bapak Suprapto, ST., MT. dan Bapak Ir. Muhammad Aswin, MT. selaku dosen pembimbing tugas akhir penulis. 4. Seluruh Dosen Teknik Elektro Unibraw atas kesediaan membagi ilmunya kepada penulis. 5. Semua Asisten, Ka. Lab serta Laboran dari Laboratorium Teknik Informatika dan Komputer yang telah memberikan banyak bantuan dan dukungan dalam menyelesaikan tugas akhir ini. 6. Murti Daryandono, M. Zaini Miftah, Aninditya, Noviatul Fardiyah, Ahmad Shoim, atas bantuan dan dukungannya selama ini.

i

7. Teman-temanku angkatan 2003 (SILVERGEN 2003) terima kasih atas segala bantuannya selama menjadi mahasiswa. 8. Semua pihak yang tidak dapat penulis sebutkan satu per satu yang terlibat baik secara langsung maupun tidak langsung demi terselesaikannya tugas akhir ini. Hanya doa yang bisa penulis berikan semoga Allah SWT memberikan pahala serta balasan kebaikan yang berlipat. Penulis menyadari bahwa tugas akhir ini masih banyak kekurangan dan masih jauh dari sempurna. Untuk itu, saran dan kritik yang membangun sangat penulis harapkan. Semoga tugas akhir ini membawa manfaat bagi penyusun maupun pihak lain yang menggunakannya. Malang, 09 Februari 2009

Penulis

ii

DAFTAR ISI

PENGANTAR……………………………………………………………..

i

DAFTAR ISI……………………………………………………………....

iii

DAFTAR TABEL………………………………………………………....

vii

DAFTAR GAMBAR……………………………………………………...

ix

DAFTAR ISTILAH……………………………………………………….

xii

ASBTRAK…………………………………………………………………

xiv

I

II

PENDAHULUAN…………………………………………………...

1

1.1

Latar Belakang…………………………………………………

1

1.2

Rumusan Masalah……………………………………………..

3

1.3

Tujuan………………………………………………………….

4

1.4

Batasan Masalah……………………………………………….

4

1.5

Manfaat………………………………………………………...

5

1.6

Sistematika Penulisan………………………………………….

5

DASAR TEORI……………………………………………………...

7

2.1

Game Networking……………………………………………..

7

2.1.1

Game Networking Protocol…………………………..

8

2.1.2

Game Networking Process……………………………

10

Protokol Komunikasi Jaringan………………………………...

10

2.2.1

TCP (Transmission Control Protocol)………………..

10

2.2.2

UDP (User Datagram Protocol)………………….......

11

2.2

2.3

Socket………………………………………………………….

11

2.3.1

TCP/IP Socket………………………………………...

11

2.3.2

UDP Socket…………………………………………...

12

2.4

Java Networking……………………………………………….

13

2.5

Rekayasa Perangkat Lunak…………………………………….

14

2.5.1

Analisis Kebutuhan (Requirement Analysis)………...

15

2.5.2

Perancangan (Design)………………………………...

17

2.5.2.1 Diagram Kelas (Class Diagram)……………

18

2.5.2.2 Diagram Sekuensial (Sequence Diagram)…..

19

Implementasi………………………………………….

20

2.5.3

iii

2.5.4

III

IV

Pengujian (Testing)…………………………………...

21

2.5.4.1 Teknik Pengujian……………………………

21

2.5.4.1.1 White-Box Testing……………….

22

2.5.4.1.2 Black-Box Testing………………..

23

2.5.4.2 Strategi Pengujian…………………………..

24

2.5.4.2.1 Unit Testing………………………

25

2.5.4.2.2 Integration Testing……………….

26

2.5.4.2.3 Validation Testing………………..

28

METODE PENELITIAN……………………………………………

29

3.1

Studi Literatur………………………………………………….

29

3.2

Analisis Kebutuhan (Requirement Analysis)………………….

29

3.3

Perancangan (Design)………………………………………….

30

3.4

Implementasi…………………………………………………...

30

3.5

Pengujian dan Analisis………………………………………...

31

3.6

Pengambilan Kesimpulan……………………………………...

31

PERANCANGAN…………………………………………………...

32

4.1

Analisis Kebutuhan (Requirement Analysis)

32

4.1.1

Identifikasi Aktor……………………………………..

32

4.1.2

Daftar Kebutuhan…………………………………….

33

4.1.3

Diagram Use Case........................................................

36

4.1.4

Skenario Use Case........................................................

39

Perancangan Perangkat Lunak…………………………………

53

4.2.1

Perancangan Umum......................................................

54

4.2.1.1 Model Komunikasi Data Pada Multiplayer

54

4.2

Tank Game......................................................

4.2.2

V

4.2.1.2 Perancangan Umum Subsistem Game Server

55

Perancangan Detail.......................................................

57

4.2.2.1 Diagram Klas (Class Diagram)......................

57

4.2.2.2 Diagram Sekuensial (Sequence Diagram)......

60

IMPLEMENTASI……………………………………………………

68

5.1

Spesifikasi Subsistem.................................................................

68

5.1.1

68

Spesifikasi Perangkat Keras..........................................

iv

5.1.2

Spesifikasi Perangkat Lunak.........................................

68

5.2

Batasan-Batasan Implementasi...................................................

69

5.3

Implementasi Klas pada File Program........................................

69

5.4

Implementasi Algoritma.............................................................

70

5.4.1

Implementasi Algoritma Bergabung Dengan Sesi Permainan......................................................................

70

5.4.2

Implementasi Algoritma Membuat Sesi Permainan.....

72

5.4.3

Implementasi Algoritma Mengirimkan Posisi Tank.....

73

5.4.4

Implementasi Algoritma Menerima Update Posisi Tank...............................................................................

74

5.4.5

Implementasi Algoritma Mengirimkan Fire State........

74

5.4.6

Implementasi Algoritma Menerima Fire State.............

76

5.4.7

Implementasi Algoritma Mengirimkan Notifikasi

5.4.8

Status Permainan...........................................................

77

Implementasi Algoritma Menerima Notifikasi Status

78

Permainan...................................................................... 5.4.9

Implementasi Algoritma Mengakhiri Sesi Permainan..

79

5.4.10 Implementasi Algoritma Meninggalkan Sesi

5.5 VI

Permainan......................................................................

80

Kendala dalam Implementasi.....................................................

81

PENGUJIAN DAN ANALISIS..........................................................

82

6.1

Pengujian....................................................................................

82

6.1.1

Pengujian Unit...............................................................

82

6.1.2

Pengujian Integrasi........................................................

89

6.1.3

Pengujian Validasi........................................................

106

6.1.3.1 Kasus Uji Validasi............................................

106

6.1.3.2 Hasil Pengujian Validasi..................................

118

Pengujian Nilai Throughput Data Game Server.........................

121

VII PENUTUP...........................................................................................

123

6.2

7.1

Kesimpulan.................................................................................

123

7.2

Saran...........................................................................................

123

DAFTAR PUSTAKA...................................................................................

124

v

DAFTAR TABEL Tabel 4.1

Deskripsi Aktor ……………………………………………...

32

Tabel 4.2

Daftar kebutuhan fungsional dan non fungsional …………...

33

Tabel 4.3

Skenario use case Mencari Sesi Permainan Yang Aktif .........

39

Tabel 4.4

Skenario use case Bergabung Dengan Sesi Permainan ..........

39

Tabel 4.5

Skenario use case Membuat Sesi Permainan ..........................

40

Tabel 4.6

Skenario use case Mengirimkan Chat ....................................

41

Tabel 4.7

Skenario use case Menerima Chat ..........................................

42

Tabel 4.8

Skenario use case Mengirimkan Notifikasi Update Tim dan Tank .........................................................................................

42

Skenario use case Menerima Notifikasi Update Tim dan Tank

43

Tabel 4.9

Tabel 4.10 Skenario use case Mengirimkan Notifikasi Update Nama Pemain .....................................................................................

44

Tabel 4.11 Skenario use case Menerima Notifikasi Update Nama Pemain

44

Tabel 4.12 Skenario use case Mengirimkan Posisi Tank ..........................

45

Tabel 4.13 Skenario use case Menerima Update Posisi Tank ..................

45

Tabel 4.14 Skenario use case Mengirimkan Fire State .............................

46

Tabel 4.15 Skenario use case Menerima Fire State ..................................

47

Tabel 4.16 Skenario use case Memperbarui Ronde ..................................

47

Tabel 4.17 Skenario use case Mengulangi Ronde ....................................

48

Tabel 4.18 Skenario use case Mengirimkan Notifikasi Ganti Peta ...........

48

Tabel 4.19 Skenario use case Menerima Notifikasi Ganti Peta ................

49

Tabel 4.20 Skenario use case Mengakhiri Sesi Permainan .......................

50

Tabel 4.21 Skenario use case Mengirimkan Notifikasi Status Permainan

50

Tabel 4.22 Skenario use case Menerima Notifikasi Status Permainan .....

51

Tabel 4.23 Skenario use case Meninggalkan Sesi Permainan ..................

52

Tabel 4.24 Skenario use case Menerima Notifikasi Pemain Yang Keluar

52

Tabel 4.25 Skenario use case Menerima Notifikasi Pemain Baru ............

53

Tabel 5.1

Spesifikasi perangkat keras komputer .....................................

68

Tabel 5.2

Spesifikasi perangkat lunak komputer ....................................

69

Tabel 5.3

Implementasi klas pada kode program *.java .........................

69

Tabel 6.1

Test case untuk pengujian unit operasi broadcast()…...…

84

vi

Tabel 6.2

Test case untuk pengujian unit operasi reply()....................

85

Tabel 6.3

Test case untuk pengujian unit operasi send()......................

86

Tabel 6.4

Test case untuk pengujian unit operasi start()....................

87

Tabel 6.5

Test case untuk pengujian unit operasi connect()................

89

Tabel 6.6

Test case untuk pengujian integrasi operasi joinGame()......

91

Tabel 6.7

Test case untuk pengujian integrasi operasi createGame().

93

Tabel 6.8

Test case untuk pengujian integrasi operasi sendTankPosition()...........................................................

95

Test case untuk pengujian integrasi operasi updateTankPosition()......................................................

97

Tabel 6.10 Test case untuk pengujian integrasi operasi sendFireState().................................................................

99

Tabel 6.11 Test case untuk pengujian integrasi operasi receiveFireState()..........................................................

101

Tabel 6.12 Test case untuk pengujian integrasi operasi sendGameState()...................................................................

103

Tabel 6.13 Test case untuk pengujian integrasi operasi updateGameState()...............................................................

106

Tabel 6.14 Test case untuk pengujian validasi ............................................

118

Tabel 6.15 Spesifikasi perangkat keras komputer .......................................

121

Tabel 6.16 Nilai Throughput Data Game Server ........................................

122

Tabel 6.9

vii

DAFTAR GAMBAR Gambar 2.1

Latency air untuk melewati sebuah selang yang ditentukan panjang selang.......................................................................

Gambar 2.2

7

Bandwith dari perjalanan air melewati selang ditentukan oleh lebar selang....................................................................

8

Gambar 2.3

Pengiriman data lewat TCP/IP..............................................

12

Gambar 2.4

Pengiriman data melalui UDP...............................................

12

Gambar 2.5

Diagram kelas dari Java networking API..............................

13

Gambar 2.6

Model pengembangan perangkat lunak waterfall (linear sequential model)..................................................................

14

Gambar 2.7

Pondasi UML………………………………………………

15

Gambar 2.8

Contoh use case diagram......................................................

16

Gambar 2.9

Contoh class diagram............................................................

18

Gambar 2.10

Contoh Sequence Diagram....................................................

20

Gambar 2.11

Transformasi flow chart ke flow graph.................................

23

Gambar 2.12

Pengujian Unit......................................................................

25

Gambar 2.13

Integrasi top-down.................................................................

26

Gambar 2.14

Integrasi bottom-up...............................................................

27

Gambar 4.1

Diagram use case sistem.......................................................

38

Gambar 4.2

Multicast transmission vs. server message exploding..........

55

Gambar 4.3

Package Diagram..................................................................

56

Gambar 4.4

Relasi antar klas....................................................................

57

Gambar 4.5

Diagram klas anggota paket net.java.dev.boombat.multiplayer.........................................

Gambar 4.6

Diagram klas anggota paket net.java.dev.boombat.multiplayer.core..................................

Gambar 4.7

58

59

Diagram klas anggota paket net.java.dev.boombat.multiplayer.message...........................

60

Gambar 4.8

Diagram Sekuensial Bergabung Dengan Sesi Permainan.....

61

Gambar 4.9

Diagram Sekuensial Membuat Sesi Permainan.....................

62

Gambar 4.10

Diagram Sekuensial Mengirimkan Posisi Tank....................

63

viii

Gambar 4.11

Diagram Sekuensial Menerima Update Posisi Tank.............

64

Gambar 4.12

Diagram Sekuensial Mengirimkan Fire State.......................

64

Gambar 4.13

Diagram Sekuensial Menerima Fire State.............................

65

Gambar 4.14

Diagram Sekuensial Mengirimkan Notifikasi Status Permainan..............................................................................

65

Gambar 4.15

Diagram Sekuensial Menerima Notifikasi Status Permainan

66

Gambar 4.16

Diagram Sekuensial Mengakhiri Sesi Permainan.................

66

Gambar 4.17

Diagram Sekuensial Meninggalkan Sesi Permainan.............

67

Gambar 5.1

Implementasi Algoritma Bergabung Dengan Sesi Permainan..............................................................................

71

Gambar 5.2

Implementasi Algoritma Membuat Sesi Permainan..............

72

Gambar 5.3

Implementasi Algoritma Mengirimkan Posisi Tank.............

73

Gambar 5.4

Implementasi Algoritma Menerima Update Posisi Tank......

74

Gambar 5.5

Implementasi Algoritma Mengirimkan Fire State................

74

Gambar 5.6

Implementasi Algoritma Menerima Fire State......................

76

Gambar 5.7

Implementasi Algoritma Mengirimkan Notifikasi Status Permainan..............................................................................

Gambar 5.8

77

Implementasi Algoritma Menerima Notifikasi Status Permainan..............................................................................

78

Gambar 5.9

Implementasi Algoritma Mengakhiri Sesi Permainan...........

80

Gambar 5.10

Implementasi Algoritma Meninggalkan Sesi Permainan......

80

Gambar 6.1

Pemodelan algoritma broadcast() ke dalam flow graph..

83

Gambar 6.2

Diagram klas dummy BroadcastTest................................

83

Gambar 6.3

Pemodelan algoritma reply() ke dalam flow graph...........

84

Gambar 6.4

Diagram klas dummy ReplyTest........................................

85

Gambar 6.5

Pemodelan algoritma send() ke dalam flow graph.............

85

Gambar 6.6

Diagram klas dummy SendTest...........................................

86

Gambar 6.7

Pemodelan algoritma start() ke dalam flow graph...........

86

Gambar 6.8

Diagram klas dummy ServerStartupTest.......................

87

Gambar 6.9

Pemodelan algoritma connect() ke dalam flow graph......

88

Gambar 6.10

Diagram klas dummy ClientConnectorTest..................

88

Gambar 6.11

Pemodelan algoritma joinGame() ke dalam flow graph....

90

ix

Gambar 6.12

Diagram klas dummy JoinGameTest..................................

Gambar 6.13

Pemodelan algoritma createGame() ke dalam flow

91

graph......................................................................................

92

Gambar 6.14

Diagram klas dummy CreateGameTest.............................

93

Gambar 6.15

Pemodelan algoritma sendTankPosition() ke dalam flow graph..............................................................................

94

Gambar 6.16

Diagram klas dummy SendTankPositionTest................

95

Gambar 6.17

Pemodelan algoritma updateTankPosition() ke dalam flow graph..............................................................................

Gambar 6.18

Diagram klas dummy UpdateTankPositionTest............

Gambar 6.19

Pemodelan algoritma sendFireState() ke dalam flow graph......................................................................................

Gambar 6.20

Diagram klas dummy SendFireStateTest.......................

Gambar 6.21

Pemodelan algoritma receiveFireState() ke dalam flow graph..............................................................................

Gambar 6.22

Diagram klas dummy ReceiveFireStateTest................

Gambar 6.23

Pemodelan algoritma sendGameState() ke dalam flow

96 96 97 98 100 101

graph......................................................................................

102

Gambar 6.24

Diagram klas dummy SendGameStateTest.......................

103

Gambar 6.25

Pemodelan algoritma updateGameState() ke dalam

Gambar 6.26

flow graph..............................................................................

104

Diagram klas dummy UpdateGameStateTest..................

105

x

DAFTAR ISTILAH Apache MINA

Sebuah framework untuk mengembangkan aplikasi jaringan yang berbasis non-blocking IO.

Creator

Pemain

yang berhasil menciptakan sebuah sesi

permainan dan mengaktifkan sebuah game server. Dead Reckoning

Client predicition atau metode lanjut yang digunakan mengurangi penggunaan bandwith jaringan dengan cara meprediksi posisi objek selanjutnya pada waktu tertentu dengan menggunakan data posisi dan kecepatan objek sekarang untuk menghitungnya.

Gameplay

Aturan atau skenario permainan yang membuat pemain tertarik dan merasakan pengalaman dalam bermain.

Game Client

Bagian perangkat lunak yang terhubung dengan game server.

Game Server

Game server merupakan perangkat lunak yang berfungsi melayani dan mengatur komunikasi data antar game client.

Java

Bahasa

pemrograman

berorientasi

objek

yang

bersifat platform independent yang dikembangkan oleh Sun Microsystems. Joiner

Pemain yang berhasil bergabung ke sebuah sesi permainan dengan cara melakukan koneksi ke sebuah game server.

LAN

Dua atau beberapa komputer yang berada dalam jarak yang terbatas satu sama lain dan terhubung satu sama lain secara langsung dan tidak langsung.

Massive Multiplayer

Game yang dimainkan oleh pemain dalam jumlah

Online game

banyak melalui Internet.

Multicast Transmission

Transmisi data yang menggunakan alamat fisik multicast data ke beberapa game client.

xi

Multiplayer Game

Game yang dimainkan oleh beberapa pemain.

Over-the-wire event

Format data yang berurutan dalam network buffer

Format

yang digunakan dalam multiplayer game.

Server Message Exploding Transmisi data dari sebuah game client ke game server yang selanjutnya akan diteruskan oleh game server ke game client – game client lainnya. Throughput

Jumlah total bits yang berhasil ditransmisikan per satuan waktu.

UDP

Transport protocol yang bersifat connectionless dan unreliable.

xii

ABSTRAK ERIQ MUHAMMAD ADAMS J. 2009. : Pengembangan Local Area Network Game Server Untuk Multiplayer Tank Game Menggunakan Teknologi Java. Skripsi Jurusan Teknik Elektro, Fakultas Teknik, Universitas Brawijaya. Dosen Pembimbing : Suprapto, ST, MT dan Ir. Muhammad Aswin, MT. Perkembangan teknologi komputasi dan jaringan yang pesat saat ini memacu inovasi dan kemajuan industri game. Game berdasarkan jumlah pemain dibagi menjadi dua, yaitu single player game dan multiplayer game. Multiplayer game berdasarkan

lokasi fisik permainan dibagi menjadi dua yaitu local

multiplayer game dan networked multiplayer game. Local multiplayer game dimainkan dalam satu mesin sedangkan networked multiplayer game dimainkan di beberapa mesin melalui jaringan. Networked multiplayer game umumnya dibedakan menjadi dua kelompok yaitu LAN (Local Area Network) Game dan WAN (Wide Area Network) Game. Aplikasi yang dibuat ini berupa LAN multiplayer tank game. Pengembangan aplikasi ini terbagi menjadi dua buah subsistem, yaitu game server dan game client. LAN game server yang bertipe listen server ini dirancang menggunakan OOAD (Object Oriented Analysis and Design) dan diimplementasikan menggunakan bahasa pemrograman Java dan Apache MINA (Multipurpose Infrastructure for Networked Applications) framework sebagai networking framework. UDP digunakan sebagai protokol komunikasi jaringan dikarenakan multiplayer tank game yang dikembangkan membutuhkan proses sinkronisasi data secara real time. Pengujian game server ini meliputi pengujian perangkat lunak menggunakan metode white-box testing dan black-box testing dan pengujian performa game server yang meliputi nilai throughput data

(Read Bytes

Throughput dan Written Bytes Throughput) yang dipengaruhi oleh jumlah game client. Hasil pengujian nilai throughput game server menunjukkan nilai throughput tidak linier. Ketidaklinieran tersebut disebabkan oleh aktivitas pemain yang berbeda sehingga mempengatuhi banyaknya data yang dikirim dan diterima. Kata Kunci : game server, multiplayer game, LAN, UDP, throughput.

xiii

BAB I PENDAHULUAN 1.1

Latar Belakang Perkembangan teknologi komputasi dan jaringan yang pesat saat ini

memacu inovasi dan kemajuan industri software atau perangkat lunak. Di mulai dengan perangkat lunak yang hanya berbasis teks (text based application) sampai dikembangkannya perangkat lunak visual atau perangkat lunak yang memiliki GUI (Graphical User Interface). Semula pendistribusian perangkat lunak tersebut hanya diperuntukkan untuk komputer, namun sekarang telah menjamah ke peralatan kecil atau small devices seperti handphone, PDA (Personal Digital Assistance), dan bahkan peralatan rumah tangga. Demikian pula tujuan pembuatan perangkat lunak yang semula ditujukan untuk membantu pekerjaan sehari-hari berkembang menjadi sarana hiburan atau entertainment media. Game adalah salah satu contoh sarana hiburan dalam bentuk software yang paling banyak diminati. Salah satu contoh game yang sering dimainkan adalah Super Mario Bros yang berjenis action 2D atau Sonic Adventures yang berjenis action 3D [CLI-04:17]. Menurut banyaknya pemain, game dibagi menjadi dua yaitu game yang hanya dimainkan oleh satu orang pemain atau yang disebut single player game dan game yang dimainkan oleh beberapa pemain atau yang disebut multiplayer game [ADA-03:XVII]. Ide timbulnya multiplayer game ini diawali pada tahun 1958 ketika William A. Hinginbotham, yang bekerja di Brookhaven National Laboratory menggunakan osiloskop untuk mensimulasikan permainan tenis yang dapat dimainkan oleh dua pemain [ARM-06:6]. Tetapi real multiplayer computer game pertama adalah spacewar yang dibuat oleh Steve Russel, J. M. Graetz dan Alan Kotok pada tahun 1961 yang di-install di komputer PDP-I [ARM-06:7]. Pesatnya perkembangan multiplayer game baru terasa pada awal tahun 90-an ketika komputer didukung dengan teknologi grafis dan suara yang realistis, dan ditambah banyaknya jumlah komputer yang terhubung dalam suatu jaringan setiap harinya.

1

Multiplayer game berdasarkan lokasi fisik permainan dibagi menjadi dua yaitu local multiplayer game dan networked multiplayer game. Local multiplayer game dimainkan dalam satu mesin sedangkan networked multiplayer game dimainkan di beberapa mesin melalui jaringan. [ADA-03:XVII]. Networked multiplayer game umumnya dibedakan menjadi dua kelompok yaitu LAN (Local Area Network) Game dan WAN (Wide Area Network) Game. LAN Game adalah game yang dimainkan di komputer-komputer yang terhubung langsung satu sama lain sedangkan WAN Game adalah game yang umumnya dimainkan melalui Internet [CLI-04:195]. Untuk mengembangkan networked multiplayer game diperlukan aplikasi di sisi client yaitu game client dan aplikasi di sisi server yaitu game server. Game server mempunyai peranan penting dalam mengatur kerja suatu networked muliplayer game. Seluruh aktifitas untuk komunikasi data antar game client diatur oleh game server. Game server harus dapat melayani game client dalam jumlah banyak secara simultan. Selain itu game server harus mempunyai kapabilitas membaca dan menulis high volume of messages dari/ke beberapa game client secara efektif [BRA-03:271] . Peran game server yang penting tersebut membuat pengembangannya menjadi kompleks. Tingkat kerumitan pengembangan game server ditentukan oleh tipe networked multiplayer game. Pengembangan game server untuk LAN (Local Area Network) game lebih sederhana daripada WAN (Wide Area Network) game. Perbedaan yang sangat mendasar antara pengembangan game server untuk LAN game dan WAN game adalah tentang cara penanganan packet latencies yaitu waktu yang dibutuhkan oleh sebuah paket data sampai ke tujuan atau penerima. Packet Latencies sangat besar di lingkungan WAN sebaliknya sangat kecil di lingkungan LAN sehingga dapat diabaikan dalam pengembangan LAN game server. Selain itu bandwith merupakan faktor kritis yang mempengaruhi pengembangan sebuah WAN game server. Tetapi faktor bandwith dapat diabaikan dalam pengembangan LAN game server karena ketersediaan bandwith yang cukup banyak di lingkungan LAN [CLI-04:197].

2

Game server dapat diklasifikasikan sebagai listen server atau dedicated server. [ANO-08] Sebuah game server dapat dikatakan sebagai listen server jika game server dan game client berjalan di mesin yang sama. Dan game server dapat dikatakan sebagai dedicated server jika game server tersebut dijalankan di dedicated hardware

serta terpisah dengan game client. Game server yang

dijalankan sebagai listen server umumnya tidak mendukung pemain dalam jumlah yang sangat banyak dibandingkan dengan game server yang dijalankan sebagai dedicated server karena keterbatasan CPU resources dan bandwith. Biasanya listen server banyak digunakan dalam LAN game. Java baik bila digunakan sebagai platform untuk mengembangkan sebuah LAN game server. Karena Java merupakan bahasa yang dirancang untuk keperluan networking sejak awal [HAR-04:23]. Java menyediakan sekumpulan Networking API (Application Programming Interface) yang lengkap sehingga mendukung pengembangan aplikasi jaringan yang kompleks. Para pengembang dapat membuat sebuah aplikasi jaringan dengan mudah bila dibandingkan dengan bahasa pemrograman yang lain seperti C atau C++ karena dihilangkannya konsep pointer yang rumit dan dukungan Collection API yang lengkap (kakas struktur data) di Java. Dan ditambah dengan keunggulan java sebagai sebuah independent platform [MOR-05:9] yang memungkinkan pengembang untuk menulis aplikasi jaringan sesekali agar dapat dijalankan di beberapa platform yang berbeda. 1.2

Rumusan Masalah Berdasarkan pada permasalahan yang telah dijelaskan pada bagian latar

belakang, maka rumusan masalah dapat disusun sebagai berikut : 1. Merancang sebuah local area network game server menggunakan bahasa pemrograman Java. 2. Implementasi local area network game server dengan Java Networking API. 3. Pengujian dan analisis kerja sistem local area network game server dalam lingkungan LAN.

3

1.3

Tujuan Tujuan penulisan tugas akhir ini adalah merancang dan mengembangkan

sebuah local area network game server menggunakan teknologi Java sehingga dapat diintegrasikan dengan 2D game client yang berbasiskan Java menjadi multiplayer tank game. 1.4

Batasan Masalah Batasan masalah yang perlu diajukan dalam pengembangan aplikasi

perangkat lunak skripsi ini, antara lain: 1. Pembahasan difokuskan pada pembuatan local area network game server. 2. Sistem operasi yang digunakan adalah Microsoft Windows XP Professional. 3. IDE (Integrated Development Environment) yang digunakan adalah Netbeans 6.1. 4. Platform pengembangan yang digunakan adalah JSE 6 (Java Standard Edition 6). 5. Networking Framework yang digunakan adalah

Apache MINA

(Multipurpose Infrastructure for Networked Applications). 6. LAN game server dijalankan sebagai listen server. 7. Pengujian performa sistem meliputi nilai throughput data yang dipengaruhi oleh banyaknya client. 8. Pengujian performa sistem menggunakan 10 buah komputer. 9. Implementasi yang dihasilkan dari sistem berupa komponen untuk game networking. 10. Skripsi ini merupakan bagian yang akan diintegrasikan dengan skripsi yang berjudul “Pengembangan 2D Game Client Untuk Multiplayer Tank Game Menggunakan Teknologi Java” yang dikerjakan oleh Murti Daryandono (Teknik Elektro Universitas Brawijaya, 2008).

4

1.5

Manfaat Manfaat penelitian ini antara lain: a. Bagi penulis 1. Menerapkan ilmu yang telah diperoleh dari Teknik Elektro Konsentrasi

Teknik

Informatika

dan

Komputer

Universitas

Brawijaya. 2. Mendapatkan pemahaman tentang perancangan dan pengembangan local area network game server yang menggunakan Java sebagai platform pengembangan. b. Bagi pengguna 1. Menyediakan sarana hiburan berupa game yang dapat dimainkan oleh beberapa pemain melalui jaringan komputer. 1.6

Sistematika Penulisan Sistematika penulisan dalam skripsi ini sebagai berikut:

BAB I

Pendahuluan Memuat latar belakang, rumusan masalah, tujuan, batasan masalah, manfaat dan sistematika penulisan.

BAB II

Dasar Teori Membahas teori dasar dan teori penunjang yang berkaitan dengan game networking, protokol komunikasi jaringan, socket,

Java

networking, analisis dan perancangan dengan UML, teknik dan strategi pengujian.

BAB III

Metode Penelitian Membahas metode yang digunakan dalam penulisan yang terdiri dari studi

literatur,

perancangan

implementasi perangkat lunak, pengambilan kesimpulan dan saran. BAB IV

Perancangan

5

perangkat

lunak,

pengujian dan analisis, serta

Membahas analisis kebutuhan dan perancangan yang sesuai dengan teori yang ada. BAB V

Implementasi Membahas tentang implementasi dari sistem aplikasi.

BAB VI

Pengujian dan Analisis Memuat hasil pengujian dan analisis terhadap sistem yang telah direalisasikan.

BAB VII

Penutup Memuat kesimpulan yang diperoleh dari pembuatan dan pengujian program, serta saran–saran untuk pengembangan lebih lanjut.

6

BAB II DASAR TEORI

Pada bab ini dibahas mengenai dasar teori yang digunakan untuk menunjang penulisan skripsi mengenai pengembangan local area network game server untuk multiplayer tank game menggunakan teknologi Java. Beberapa dasar teori yang dimaksud diantaranya adalah game networking, game networking protocol, game networking process, protokol komunikasi jaringan, socket, Java networking, analisis dan perancangan dengan UML, teknik dan strategi pengujian. 2.1

Game Networking Networking untuk game dibagi menjadi dua kategori besar yaitu LAN

(Local Area Network) game dan WAN (Wide Area Network) game. Perancangan dan implementasi LAN game lebih sederhana dari pada WAN game. Perbedaan mendasar terdapat pada cara penanganan latency, dan cara komputer tersebut dihubungkan di jaringan (tipe koneksi jaringan) [CLI-04:195]. Latency, waktu yang dibutuhkan oleh pengiriman sebuah paket data sampai ke tujuan. Besarnya Latency dipengaruhi jarak antara mesin pengirim dan mesin penerima dalam jaringan. Semakin jauh jarak antara mesin pengirim dan penerima semakin besar jumlah latency-nya. Hubungan latency ini dapat dianalogikan dengan latency air melewati sebuah selang [CLI-04:196]. Hubungan latency ini ditunjukkan pada Gambar 2.1.

Gambar 2.1 Latency air untuk melewati sebuah selang yang ditentukan panjang selang. Sumber : [CLI-04:196]

7

Bandwith, faktor kritis yang mempengaruhi besarnya latency. Bandwith merupakan jumlah byte yang dapat dikirim per satuan waktu [CLI-04:197]. Biasanya besarnya bandwith diukur dalam satuan bytes/seconds. Semakin besar bandwith semakin kecil latency-nya. Bandwith dapat dianalogikan sebagai lebar selang air. Analogi ini ditunjukkan pada Gambar 2.2.

Gambar 2.2 Bandwith dari perjalanan air melewati selang ditentukan oleh lebar selang. Sumber : [CLI-04:197]

Komputer yang dipakai dalam WAN networked multiplayer game mempunyai tipe koneksi yang berbeda. Tipe koneksi yang umum dipakai yaitu koneksi dengan analog modem (56K), DSL modem, atau koneksi secara langsung seperti T1 dan T3 lines. Setiap tipe koneksi tersebut mempunyai karakteristik yang berbeda terhadap latency dan bandwith dalam sebuah WAN networked multiplayer game. Sedangkan komputer desktop yang dihubungkan di sebuah LAN melalui sebuah Ethernet port atau wireless ethernet connection (80211.b or 80211.g) dapat mengabaikan latency dan bandwith. Hal ini dikarenakan kedua koneksi tersebut menambahkan latency yang sangat kecil dan menyediakan bandwith dalam jumlah besar dari pada bandwith yang dibutuhkan oleh game [CLI-04:197]. 2.1.1

Game Networking Protocol Game networking protocol untuk LAN game dapat diklasifikasikan

menjadi dua macam cara yaitu, klasifikasi menurut cara bersinkronisasi dan cara berkomunikasi.

Klasifikasi

game

networking

8

protocol

menurut

cara

bersinkronisasi

dibagi

menjadi

dua

Synchronization. Sedangkan menurut cara

yaitu,

Lock-step

dan

Open-Loop

berkomunikasi dibagi menjadi dua

yaitu, Controller-State dan Object-State Communication [CLI-04:232]. Lock-step game muncul dari model single player game. Dalam single player game, controller dibaca sekali setiap frame, posisi baru dihitung, dan game logic diproses. Frame yang dihasilkan akan di-render dan di-flip ke layar. Sebuah lock-step game bekerja dengan cara yang sama. Setelah

game membaca semua

controller, game mengirimkan sebuah paket data ke semua pemain dalam game kemudian menunggu sampai semua pemain bergiliran mengirimkan paket data controller sebelum mengkalkulasi hasilnya. Lock-step game mungkin merupakan model termudah karena sesuai dengan yang ada di game. Dan juga relatif mudah untuk menambahkan cheat protection dalam game yaitu, dengan cara mengirimkan data secara rutin pada game state dan controller sehingga game session dapat melakukan sanity-check satu sama lain. Jika sebuah client mengirimkan state yang berbeda dengan client-client lainnya maka dapat dinyatakan secara jelas telah terjadi cheat atau bug. Kelemahan dari pendekatan ini adalah setiap pemain harus mengirimkan input untuk game agar game dapat berlanjut. Keterbatasan ini menyebabkan lock-step game tidak sesuai untuk permainan Internet karena latency dapat menghentikan game. Dan hal ini berarti frame rate semua pemain bergantung atau terikat dengan frame rate pemain yang terendah. Open-loop asynchronous game sangat berbeda dengan lock-step game. Sebuah open-loop asynchronous game berjalan pada game loop dengan kecepatan tertinggi (maximum frame rate). Secara periodik, game meperbarui data berdasarkan data yang diterima dan data sebelumnya. Kemudian game memodifikasi data pemain lain dengan cara memperkirakan apa yang dikerjakan pemain lain. Cara atau teknik ini dinamakan dengan dead reckoning. Tipe game ini sangat sesuai untuk Internet games. Open-loop asynchronous game bersifat latency-immune dan setiap pemain berjalan pada maximum frame rate. Tetapi open-loop asynchronous game ini mempunyai kelemahan terbesar yaitu masalah security. Dalam prakteknya sebagian besar Internet games yang ada sekarang ini

9

merupakan model open-loop asynchronous yang telah dimodifikasi dimana salah satu pemain bertindak sebagai server dan dikontrol oleh game maker. Controller-state communication menurun dari model single player game. Game akan membaca controller dan mengirimkan sebuah raw packet setiap frame-nya

sehingga

tidak

menyediakan

informasi

yang

cukup

untuk

memperkirakan paket data selanjutnya. Tipe komunikasi ini sesuai untuk lock-step game dan tidak sesuai untuk open-loop asynchronous game. Object-state

communication

berbeda

dengan

controller-state

communication. Paket data yang dikirimkan bukan berupa raw packet namun paket data yang berisi seluruh state dan telah dikalkulasi sebelumnya. Object-state communication ini sesuai dengan open-loop asynchronous game yang menggunakan teknik dead reckoning. 2.1.2

Game Networking Process Secara umum game networking process untuk LAN game dapat dibagi

menjadi tiga [CLI-04:207] : •

Discovery, proses untuk menemukan game server atau sesi permainan yang aktif

•

Creating game session, proses untuk membuat sesi permainan yang baru dan sekaligus mengaktifkan game server.

•

Joining game session, proses untuk bergabung ke sesi permainan yang aktif.

2.2

Protokol Komunikasi Jaringan Pengiriman data di jaringan membutuhkan berbagai macam metode.

Metode ini yang disebut sebagai protokol. TCP/IP dan UDP merupakan protokol jaringan yang banyak digunakan. 2.2.1

TCP (Transmission Control Protocol) TCP (Transmission Control Protocol) merupakan protokol yang

dirancang khusus untuk menyediakan sebuah reliable end-to-end byte stream melalui sebuah unreliable internetwork [TAN-03:493]. Hal ini berarti setiap paket data yang dikirim melalui TCP dijamin untuk sampai ke penerima sesuai dengan

10

urutan paket data yang benar. Sebuah internetwork berbeda dengan sebuah single network karena internetwork memiliki berbagai macam topologi, bandwith, delay, ukuran paket yang berbeda.

TCP dirancang untuk beradaptasi dengan

karakteristik dari internetwork dan handal dalam menghadapi berbagai macam bentuk failures. TCP didefinisikan dalam RFC 793, RFC 1122, dan RFC 1323. Semua koneksi dari TCP adalah full duplex dan point-to point. [TAN03:494] Full duplex berarti lalu lintas data dapat berjalan dua arah pada waktu yang sama. Sedangkan point-to-point berarti setiap koneksi pasti mempunyai dua buah end point. Karena itu TCP tidak mendukung multicasting atau broadcasting. 2.2.2

UDP (User Datagram Protocol) UDP (User Datagram Protocol) merupakan transport protocol yang

bersifat connectionless. [TAN-03:487] Protokol ini menyediakan sebuah cara kepada aplikasi untuk mengenkapsulasi IP datagrams tanpa harus menjaga koneksi tersebut. UDP tidak menjamin setiap paket data yang dikirim sampai ke penerima dengan urutan yang benar (unreliable). Hal ini membuat UDP sebagai protokol yang lebih sederhana daripada TCP. Manfaat dari UDP yang paling besar adalah mendukung beberapa penerima untuk sebuah pengiriman paket data melalui sebuah multicast channel. Dalam pengembangan game server UDP multicast sangat penting digunakan untuk melakukan pekerjaan seperti mengetahui game dalam sebuah jaringan. 2.3

Socket Istilah socket pertama kali dikenalkan di Berkeley Unix dan telah

diadopsi menjadi sebuah standar untuk menjelaskan koneksi TCP/IP dan UDP yang melewati sistem operasi yang berbeda. Socket merupakan sebuah end point untuk sebuah komunikasi jaringan [CLI-04:200]. 2.3.1

TCP/IP Socket Koneksi TCP/IP dapat dikatakan sebagai dua kabel virtual (virtual wire)

yang saling terhubung antara dua buah komputer. Sedangkan TCP/IP socket dapat dikatakan sebagai tempat ditancapkannya kabel tersebut di kedua komputer. TCP/IP socket dapat digunakan sebagai host atau client. Sebuah host socket akan

11

menunggu koneksi dari client dan mempunyai nomor identifikasi yang disebut port. Gambar 2.3 menunjukkan pengiriman data melewati TCP/IP.

Gambar 2.3 Pengiriman data lewat TCP/IP. Sumber : [CLI-04:200]

2.3.2

UDP Socket Koneksi UDP dapat dikatakan seperti koneksi tanpa kabel (wireless

connection). Sedangkan UDP socket dapat dikatakan sebagai tempat untuk menerima dan mengirim paket data dari/ke beberapa mesin. Semua paket yang dikirimkan melalui UDP harus dilabeli alamat mesin dan port number yang digunakan. Penerimaan dan pengiriman paket data dari/ke beberapa mesin dapat menggunakan sebuah UDP socket yang sama. Gambar 2.4 menunjukkan pengiriman data melalui UDP.

Gambar 2.4 Pengiriman data melalui UDP .

12

Sumber : [CLI-04:200]

2.4

Java Networking Java sebagai platform pengembangan menyediakan dukungan API

(Application Programming Interface) yang beragam. Java networking API adalah sekumpulan API yang mempermudah pengembang untuk membuat aplikasi jaringan. Karena ketersediaan API yang lengkap membuat Java baik digunakan untuk pengembangan aplikasi Internet. Pengembangan aplikasi jaringan di Java lebih mudah bila dibandingkan dengan C/C++. Hal ini dikarenakan Java menghilangkan konsep pointer yang rumit dan sering menimbulkan masalah. Para pengembang cukup sesekali menulis aplikasi jaringan untuk digunakan di beberapa sistem operasi yang berbeda karena sifat Java sebagai platform independent [MOR-05:9]. Selain dukungan untuk low level network communication Java juga mendukung untuk higher level network communication untuk keperluan sistem terdistribusi seperti RMI (Remote Method Invocation) dan CORBA (Common Object Request Broker Architecture). RMI dan CORBA membolehkan pemanggilan method

sebuah objek dari sebuah

remote application yang dieksekusi dalam JVM (Java Virtual Machine) yang berbeda. Java networking API sebagian besar terdapat di paket java.net. Paket java.net berisi sekumpulan kelas dasar untuk membangun sebuah aplikasi jaringan dan network service seperti UDP packet, TCP socket, IP address, URL dan HTTP connection. Gambar 2.5 menunjukkan diagram kelas dari Java networking API.

Gambar 2.5 Diagram kelas dari Java networking API.

13

Sumber : [MOR-05:714]

2.5

Rekayasa Perangkat Lunak Kompleksitas

sistem

yang

semakin

tinggi

membuat

beban

pengembangan perangkat lunak semakin sulit [FOW-02:18]. Oleh karena itu diperlukan adanya metode pengembangan untuk menghasilkan perangkat lunak yang berkualitas. Dalam hal ini dibutuhkan suatu rekayasa terhadap perangkat lunak (Software Engineering). Menurut IEEE, rekayasa perangkat lunak adalah penerapan yang sistematis, disiplin, serta pendekatan yang terukur terhadap pengembangan, pengoperasian, dan pemeliharaan perangkat lunak. [PRE-01:20]. Untuk menyelesaikan masalah dalam lingkungan industri, seorang software engineer atau sekumpulan software engineer harus menggabungkan strategi pengembangan yang meliputi proses, metode, dan alat bantu. Strategi ini yang kemudian sering disebut sebagai model proses (process model) atau paradigma rekayasa perangkat lunak (software engineering paradigm) . Model proses untuk rekayasa perangkat lunak dipilih sesuai dengan sifat dari proyek dan aplikasi yang akan dibuat. Salah satu dari model proses yang digunakan adalah linear sequential model. Linear sequential model biasa disebut sebagai classic life cycle atau waterfall model. Model proses waterfall ini merekomendasikan pendekatan yang sistematis dan terurut (systematic and sequential approach) untuk pengembangan perangkat lunak yang dimulai dari analisis kebutuhan (requirement analysis), perancangan (design), implementasi (coding), pengujian (testing), dan pemeliharaan (maintenance) [PRE-01:28]. Proses pengembangan menggunakan model proses waterfall ini terlihat pada Gambar 2.6.

Gambar 2.6 Model pengembangan perangkat lunak waterfall (linear sequential model).

14

Sumber : [PRE-01:29]

Proses analisis kebutuhan, perancangan, implementasi, dan pengujian perangkat lunak dapat dikelompokkan menjadi dua metode, yaitu metode struktural dan metode berorientasi objek. Pada skripsi ini digunakan metode analisis kebutuhan, perancangan, implementasi, dan pengujian berorientasi objek menggunakan bahasa pemodelan UML (Unified Modelling Language). UML adalah

bahasa

untuk

menggambarkan

(visualizing),

menspesifikasikan

(specifying), membangun (constructing), dan mendokumentasikan (documenting) artefak dari sebuah sistem perangkat lunak [KNO-01:44]. UML dirancang oleh Grady Booch, Ivar Jacobson, dan James Rumbaugh untuk menyatukan bermacam - macam bahasa pemodelan dan metode berorientasi objek dengan cara menggabungkan bahasa pemodelan dan metode berorientasi objek terbaik yang telah ada [KNO-01:46]. Hal ini ditunjukkan pada Gambar 2.7.

Gambar 2.7 Pondasi UML Sumber : [KNO-01:47]

2.5.1

Analisis Kebutuhan (Requirement Analysis) Objektif dari analisis berorientasi objek (Object Oriented Analysis/OOA)

adalah untuk mengembangkan sebuah model yang menjelaskan perangkat lunak

15

bekerja sesuai kebutuhan yang didefinisikan oleh customer [PRE-01:572]. Proses OOA tidak dimulai dengan perhatiannya terhadap objek-objek. Namun proses OOA dimulai dengan pemahaman oleh siapa sistem tersebut digunakan. Aktor sistem tersebut dapat berupa orang jika sistem tersebut merupakan human interactive system atau berupa mesin jika sistem tersebut dilibatkan dalam process control atau bahkan berupa program lain jika sistem tersebut ditujukan untuk mengkoordinasi dan mengontrol aplikasi-aplikasi lain [PRE-01:581]. Diagram pemodelan aplikasi keseluruhan berdasarkan analisis kebutuhan yang dilakukan digambarkan dengan use case diagram. Use case diagram memodelkan sistem dari perspektif end-user. Selama penggalian kebutuhan sistem, use case harus mampu mencapai beberapa objektif. Objektif-objektif

tersebut

antara

lain

adalah

use

case

mampu

untuk

mendefinisikan kebutuhan yang bersifat fungsional dan operasional sistem dengan cara mendefinisikan skenario yang disetujui oleh end-user dan software engineer team, use case harus menyediakan penjelasan yang jelas dan tidak ambigu tentang cara end-user berinteraksi dengan sistem, dan use case harus menyediakan sebuah dasar untuk validation testing [PRE-01:581]. Contoh use case diagram ditunjukkan pada Gambar 2.8.

Gambar 2.8 Contoh use case diagram. Sumber : [FOW-03:147]

16

Use case diagram terdiri dari aktor, use case, dan relationship. Aktor merepresentasikan entitas eksternal yang berinteraksi dengan sistem dan diidentifikasi berdasarkan role. Aktor dapat berupa users, external systems, dan external devices [KNO-01:113]. Use case merepresentasikan business process yang dilakukan oleh aktor. Relationship dalam use case diagram ada tiga macam yaitu hubungan antara aktor dan use case (associations),

hubungan

ketergantungan antara dua use case (dependencies), dan hubungan antar aktor dimana salah satu aktor dapat berpartisipasi dalam use case aktor lainnya (generalizations) [KNO-01:114]. Selain itu use case diagram menyediakan standard stereotypes yaitu include dan extend. Include stereotype menandakan sebuah use case harus melakukan atau terlibat dalam use case lain. Sedangkan extend stereotype menandakan sebuah use case boleh terlibat dalam use case lain atau bersifat opsional [KNO-01:116]. 2.5.2

Perancangan (Design) Perancangan

berorientasi

objek

(Object

Oriented

Design/OOD)

mentransformasikan model yang dibuat menggunakan OOA. OOD membutuhkan definisi sebuah multilayered software architecture, spesifikasi subsistem yang menunjukkan fungsi-fungsi yang dibutuhkan dan menyediakan dukungan infrastruktur, deskripsi dari objek-objek yang membangun sistem, serta deskripsi dari mekanisme komunikasi yang membolehkan aliran data antar layer, subsistem, dan objek-objek. OOD dibagi dalam dua aktifitas besar yaitu, system design dan object design. System design membuat product architecture, mendefinisikan layer-layer yang melakukan fungsi sistem tertentu dan mengidentifikasi kelaskelas yang dienkapsulasi oleh subsistem yang berada pada setiap layer. Sebagai tambahan system design berhubungan dengan tiga spesifikasi komponen yaitu, user interface, data management functions, dan task management facilities. Sedangkan object design bertumpu pada detail internal individu – individu kelas, mendefinisikan atribut-atribut, operasi-operasi dan message [PRE-01:603]. Pada tahap perancangan di skripsi ini, digunakan pemodelan dengan menggunakan dua macam diagram, yaitu class diagram dan sequence diagram.

17

2.5.2.1

Diagram Kelas (Class Diagram) Class adalah sebuah blueprint dari individu – individu objek yang

diciptakan

[ZAK-06:57].

Objek-objek

yang

diciptakan

mempunyai

dua

karakteristik yaitu, memiliki state dan behaviour [ZAK-06:54]. Class diagram digunakan untuk menjelaskan tipe dari objek –objek yang ada di sistem dan berbagai macam bentuk static relationship yang ada diantara objek – objek tersebut. Class diagram juga menunjukkan properties dan operations dari sebuah class serta constraints ketika

objek-objek

tersebut

dihubungkan [FOW-03:69]. Contoh class diagram ditunjukkan pada Gambar 2.9.

Gambar 2.9 Contoh class diagram Sumber : [FOW-03:70]

Notasi kotak pada class diagram pada Gambar 2.9 adalah class yang dibagi menjadi 3 bagian yaitu, nama kelas, attributes, dan operations. Atributes dan operations dalam class dapat memiliki visibility public (dinotasikan dengan

18

simbol +), private (dinotasikan dengan simbol -), protected (dinotasikan dengan simbol #), dan package (dinotasikan dengan simbol ~) [FOW-03:126].

Untuk

menghubungkan kelas-kelas dibutuhkan relasi (relationship). Hubungan antar class dapat dijelaskan sebagai berikut [PIL-05:51] : •

Asosiasi (Assocciation), yaitu hubungan yang mengindikasikan sebuah class tetap memiliki hubungan dengan class lain dalam waktu yang lama. Hubungan ini dapat dibaca sebagai “…has a…” relationship. Asosiasi memiliki notasi untuk menunjukkan navigability. Navigability dapat berupa satu arah (unidirectional) dan dua arah (bidirectional). Multiplicity dalam hubungan asosiasi digunakan untuk mengindikasikan banyaknya instances yang terlibat dalam hubungan asosiasi tersebut.

•

Dependensi (Dependency), yaitu hubungan

yang mengindikasikan

sebuah class menggunakan class lain. •

Agregasi (Aggregation), yaitu hubungan yang menyiratkan kepemilikan (ownership). Hubungan ini dapat dibaca sebagai “…owns a…” relationship.

•

Komposisi (Composition), yaitu hubungan yang menggambarkan wholepart relationship. Hubungan ini dapat dibaca sebagai “…is part of…” relationship.

•

Generalisasi (Generalization), yaitu hubungan yang digunakan untuk mengeluarkan kesamaan (commonality) diantara kelas-kelas yang berbeda. Generalisasi dapat dibaca sebagai “…is a…” realitonship.

2.5.2.2

Diagram Sekuensial (Sequence Diagram) Sequence diagram menggambarkan dynamic behaviour dari elemen -

elemen sistem ketika berinteraksi [ALH-03:136]. Sequence diagram diorganisir dalam dua sumbu yaitu, sumbu horisontal dan vertikal. Sumbu horisontal menunjukkan elemen - elemen yang terlibat dalam interaksi. Sedangkan sumbu vertikal menunjukkan time proceeding. Hal ini dapat ditunjukkan pada Gambar 2.10. Sequence diagram terdiri dari beberapa elemen [ALH-03:146] : •

Class roles, yaitu elemen yang digunakan untuk level spesifikasi dari kolaborasi (specification-level collaborations).

19

•

Specific objects, yaitu objek yang sesuai dengan class roles dan objek lain yang digunakan untuk instance-level collaborations.

•

Lifeline, yaitu elemen yang merepresentasikan keberadaan elemen dari waktu ke waktu.

•

Activations, yaitu elemen yang merepresentasikan waktu sebuah elemen beroperasi.

Gambar 2.10 Contoh Sequence Diagram Sumber : [FOW-03:91]

2.5.3

Implementasi Implementasi perangkat lunak dilakukan untuk merealisasikan desain

dari perangkat lunak menggunakan bahasa pemrograman berorientasi objek (Object

Oriented

Programming

Languages/OOP).

Bahasa

pemrograman

berorientasi objek yang digunakan pada skripsi ini adalah Java. Java dirancang dengan beberapa fitur menarik [MOR-05:31]: •

Java adalah bahasa berorientasi objek. Bahasa berorientasi objek membagi program menjadi beberapa modul yang terpisah, yang dinamakan objek,

20

yang mengenkapsulasi data dan operasi program. Tidak seperti bahasa C++ yang memasukkan fitur object-oriented kedalam bahasa C, Java dirancang dari awal sebagai sebuah bahasa berorientasi objek. •

Java merupakan bahasa yang aman (secure language). Java berisi fitur yang dapat memproteksi dari untrusted code atau virus yang dapat merusak sistem.

•

Java adalah bahasa tangguh (robust). Error di dalam program Java tidak menyebabkan sistem menjadi crash. Java memiliki fitur yang dapat mendeteksi error sebelum program tersebut dijalankan.

•

Java

merupakan

platform

independent.

Sebuah

platform,

secara

kontekstual merupakan sejenis sistem komputer seperti Machintosh atau Windows. Java memiliki trademark “Write once, run anywhere” yang berarti program Java dapat dijalankan pada sistem komputer yang berbeda tanpa mengubah kode program. •

Java merupakan bahasa terdistribusi (distributed language). Program Java dapat dirancang untuk dijalankan dalam jaringan komputer. Java didukung dengan banyaknya code libraries untuk membuat sistem perangkat lunak Internet.

2.5.4

Pengujian (Testing) Arsitektur dari perangkat lunak berorientasi objek menghasilkan

sekumpulan layered subsystems yang mengenkapsulasi kelas-kelas yang berkolaborasi. Setiap elemen sistem (subsistem dan class) melakukan fungsi yang membantu untuk mencapai kebutuhan sistem. Hal ini sangat penting untuk menguji sebuah OO system pada berbagai macam level yang berbeda dalam sebuah usaha untuk menemukan kesalahan-kesalahan yang mungkin terjadi dari kolaborasi kelas-kelas dan komunikasi subsistem melewati architetural layer [PRE-01:631]. 2.5.4.1

Teknik Pengujian Pengujian perangkat lunak memerlukan perancangan kasus uji (test case)

agar dapat menemukan kesalahan dalam waktu singkat dan usaha minimum. Berbagai macam metode perancangan kasus uji telah berevolusi. Metode-metode

21

ini menyediakan developer pendekatan sistematis untuk pengujian. Terlebih lagi metode-metode ini menyediakan mekanisme yang dapat membantu memastikan kelengkapan dari pengujian dan menyediakan kemungkinan tertinggi untuk menemukan kesalahan-kesalahan dalam perangkat lunak [PRE-01:443]. Teknik atau metode perancangan kasus uji yang digunakan adalah black-box testing dan white-box testing. 2.5.4.1.1 White-Box Testing White-box testing atau glass-box testing

merupakan sebuah metode

perancangan kasus uji yang menggunakan struktur kontrol dari perancangan prosedural untuk memperoleh kasus uji [PRE-01:444]. Ada dua jenis pengujian yang termasuk white-box testing yaitu basis path testing dan control structure testing. Pada skripsi ini menggunakan basis path testing yang diusulkan pertama kali oleh Tom McCabe [PRE-01:445]. Basis path testing ini memungkinkan perancang kasus uji memperoleh ukuran kompleksitas logis dari sebuah perancangan prosedural dan menggunakan pengukuran ini sebagai pedoman untuk mendefinisikan basis set dari jalur eksekusi (execution path). Test case yang dilakukan untuk menggunakan basis set tersebut dijamin untuk menggunakan setiap statement di dalam program paling tidak sekali selama pengujian. Sebelum metode basis path dapat diperkenalkan, notasi sederhana untuk representasi aliran kontrol yang disebut diagram alir (flow graph) harus diperkenalkan. Setiap representasi desain prosedural yang berupa flow chart dapat diterjemahkan ke dalam flow graph. Gambar 2.11 menunjukkan transformasi flow chart ke flow graph. Setelah flow graph didefinisikan maka harus ditentukan ukuran kompleksitas (cyclomatic complexity).

22

Gambar 2.11 Transformasi flow chart ke flow graph Sumber : [PRE-01:447]

Cyclomatic

complexity

adalah

metriks

perangkat

lunak

yang

memberikan pengukuran kuantitatif terhadap kompleksitas logis suatu program. Bila metriks ini digunakan dalam konteks metode pengujian basis path, maka nilai yang terhitung untuk cyclomatic complexity menentukan jumlah jalur independen (independent path) dalam basis set suatu program dan memberi batas atas bagi jumlah pengujian yang diharus dilakukan untuk memastikan bahwa semua statemen telah dieksekusi sedikitnya satu kali. Jalur independen adalah jalur yang melalui program yang mengenalkan sedikitnya satu rangkaian statement proses baru atau suatu kondisi baru. Untuk menentukan cyclomatic complexity bisa dilakukan dengan beberapa cara, diantaranya [PRE-01:448]: 1. Jumlah region pada flow graph sesuai dengan cyclomatic complexity. 2. Cyclomatic complexity V(G), untuk grafik G adalah V(G) = E – N + 2, dimana E adalah jumlah edge, dan N adalah jumlah node. 3. V(G) = P + 1, dimana P adalah jumlah predicate node yaitu node yang merupakan kondisi (ada 2 atau lebih edge akan keluar node ini). 2.5.4.1.2 Black-Box Testing Black-box testing atau behavioral testing berfokus pada persyaratan fungsional perangkat lunak [PRE-01:459]. Dengan demikian, pengujian black-box

23

memungkinkan perekayasa perangkat lunak mendapatkan serangkaian kondisi input yang sepenuhnya menggunakan semua persyaratan fungsional untuk semua program. Pengujian black-box bukan merupakan alternatif dari teknik white-box, tetapi merupakan pendekatan komplementer yang kemungkinan besar mampu mengungkap kelas kesalahan daripada metode white-box. Pengujian black-box berusaha menemukan kesalahan dalam kategori berikut (1) fungsi-fungsi yang tidak benar atau hilang. (2) kesalahan interface, (3) kesalahan dalam struktur data atau akses database eksternal, (4) kesalahan kinerja, (5) inisialisasi dan kesalahan terminasi. Tidak seperti pengujian white-box, yang dilakukan pada saat awal proses pengujian, pengujian black-box cenderung diaplikasikan selama tahap akhir pengujian. Karena pengujian black-box memperhatikan struktur kontrol, maka perhatian berfokus pada domain informasi. Pengujian didesain untuk menjawab pertanyaan-pertanyaan berikut :

2.5.4.2

•

Bagaimana validitas fungsional diuji ?

•

Kelas input apa yang akan membuat test case menjadi baik ?

•

Apakah sistem sangat sensitif terhadap harga input tertentu ?

•

Bagaimana batasan dari suatu data diisolasi ?

•

Kecepatan dan volume data apa yang dapat ditolerir oleh sistem ?

•

Apa pengaruh kombinasi tertentu dari data terhadap operasi sistem ? Strategi Pengujian Strategi untuk pengujian perangkat lunak mengintegrasikan metode

desain test case perangkat lunak ke dalam sederetan langkah yang direncanakan dengan baik, dan hasilnya adalah konstruksi perangkat lunak yang berhasil [PRE01:477]. Sejumlah strategi pengujian perangkat lunak telah diusulkan di dalam literatur. Strategi pengujian harus mengakomodasi pengujian tingkat rendah yang diperlukan untuk membuktikan bahwa segmen kode sumber yang kecil telah diimplementasikan dengan tepat, demikian juga pengujian tingkat tinggi yang memvalidasi fungsi-fungsi sistem mayor yang berlawanan dengan kebutuhan pelanggan. Proses pengujian dimulai dengan pengujian yang berfokus pada setiap modul secara individual (unit testing), dilanjutkan dengan pengujian integrasi

24

(integration testing) dan berakhir pada pengujian validasi (validation testing) [PRE-01:481]. 2.5.4.2.1 Unit Testing Pengujian unit berfokus pada usaha verifikasi pada inti terkecil dari desain perangkat lunak, yakni modul. Dengan menggunakan gambaran desain prosedural sebagai panduan, jalur kontrol yang penting diuji untuk mengungkap kesalahan di dalam batas modul tersebut. Kompleksitas relatif dari pengujian dan kesalahan yang diungkap dibatasi oleh ruang lingkup batasan yag dibangun untuk pengujian unit. Pengujian unit biasanya berorientasi pada white-box, dan langkahnya dapat dilakukan secara paralel untuk model bertingkat [PRE-01:485]. Pengujian yang terjadi sebagai bagian dari unti digambarkan secara skematis pada Gambar 2.12. Interface modul diuji untuk memastikan bahwa informasi secara tepat mengalir masuk dan keluar dari inti program yang diuji. Struktur data lokal diuji untuk memastikan bahwa data yang tersimpan secara temporal dapat tetap menjaga integritasnya selama semua langkah di dalam suatu algoritma dieksekusi. Kondisi batas diuji untuk memastikan bahwa modul beroperasi dengan tepat pada batas yang ditentukan untuk membatasi pemrosesan. Semua jalur independen (jalur dasar) yang melalui struktur kontrol dipakai sedikitnya satu kali. Dan akhirnya, penanganan kesalahan uji [PRE-01:485].

Gambar 2.12 Pengujian Unit Sumber : [PRE-01:487]

25

2.5.4.2.2 Integration Testing Pengujian integrasi adalah teknik sistematis untuk mengkonstruksi struktur program sambil melakukan pengujian untuk mengungkap kesalahan sehubungan dengan interfacing. Sasarannya adalah untuk mengambil modul yang dikenai pengujian unit dan membangun struktur program yang telah ditentukan oleh desain. Integration testing berorientasi black box dan mempunyai dua pola pengujian yaitu integrasi top-down (top-down integration) dan integrasi bottom-up (bottom-up integration) [PRE-01:488]. Integrasi top-down adalah pendekatan inkremental terhadap struktur program. Modul diintegrasikan dengan menggerakkan ke bawah melalui hirarki kontrol, dimulai dengan modul kontrol utama (program utama). Subordinat program terhadap modul kontrol utama digabungkan ke dalam struktur dengan cara depth-first atau breadth-first [PRE-01:489]. Gambar 2.13 menunjukkan pola pengujian integrasi top-down.

Gambar 2.13 Integrasi top-down Sumber : [PRE-01:489]

26

Proses integrasi top-down dilakukan dalam lima langkah [PRE-01:489]: •

Modul kontrol utama digunakan sebagai test driver dan stub digunakan untuk menggantikan semua komponen dibawahnya.

•

Pemilihan pendekatan integrasi yang diinginkan (depth atau breadth first).

•

Pengujian dikerjakan untuk setiap komponen yang diintegrasikan.

•

Stub

digantikan

dengan

komponen

yang

sebenarnya

setelah

menyelesaikan serangkaian pengujian. •

Proses akan terus dilakukan sampai membentuk sebuah perangkat lunak yang utuh. Pengujian integrasi bottom-up memulai konstruksi dan pengujian dengan

modul atomik (modul pada tingkat paling rendah pada struktur program). Hal ini terlihat pada Gambar 2.14. Karena modul diintegrasikan dari bawah ke atas, maka pemrosesan yang diperlukan untuk modul subordinat ke suatu tingkat yang diberikan akan selalu tersedia dan kebutuhan akan stub dapat dieliminasi [PRE01:490].

Gambar 2.14 Integrasi bottom-up Sumber : [PRE-01:491]

27

Integrasi bottom-up dapat diimplementasi dengan langkah-langkah berikut [PRE-01:490]: •

Komponen pada level terendah digabung ke dalam sebuah sub fungsi (cluster).

•

Driver akan dibuat untuk menguji setiap cluster.

•

Driver akan diganti dengan modul sesungguhnya setelah sub fungsi teruji.

•

Proses akan terus dilakukan sampai membentuk sebuah perangkat lunak yang utuh.

2.5.4.2.3 Validation Testing Pada kulminasi pengujian terintegrasi, perangkat lunak secara lengkap dirakit sebagai suatu paket; kesalahan interfacing telah diungkap dan dikoreksi, dan seri akhir dari pengujian perangkat lunak, yaitu pengujian validasi dapat dimulai. Validasi dapat ditentukan dengan berbagai cara, tetapi definisi yang sederhana adalah bahwa validasi berhasil bila perangkat lunak berfungsi dengan cara yang dapat diharapkan secara bertanggung jawab oleh pelanggan. Validasi perangkat

lunak

memperlihatkan

dicapai

melalui

konformitas

sederetan

dengan

pengujian

persyaratan.

black-box

Rencana

yang

pengujian

menguraikan kelas-kelas pengujian yang akan dilakukan, dan prosedur pengujian menentukan test case spesifik yang akan

digunakan

untuk mengungkap

kesalahan dalam konformitas dengan persyaratan. Baik rencana dan prosedur didesain untuk memastikan apakah semua persyaratan fungsional dipenuhi; semua persyaratan kinerja dicapai; dokumentasi betul dan direkayasa oleh manusia: dan persyaratan lainnya dipenuhi (transportabilitas, kompatibilitas, pembetulan kesalahan, maintanabilitas) [PRE-01:495].

28

BAB III METODE PENELITIAN Pada bab ini dijelaskan langkah-langkah yang akan dilakukan dalam perancangan, implementasi dan pengujian dari aplikasi perangkat lunak yang akan dibuat. Kesimpulan dan saran disertakan sebagai catatan atas aplikasi dan kemungkinan arah pengembangan aplikasi selanjutnya. 3.1

Studi Literatur Studi literatur menjelaskan dasar teori yang digunakan untuk menunjang

penulisan skripsi. Teori-teori pendukung tersebut meliputi: a. Game Networking •

Game Networking Protocol

•

Game Networking Process

b. Protokol Komunikasi Jaringan •

TCP (Transmission Control Protocol)

•

UDP (User Datagram Protocol)

c. Socket •

TCP (Transmission Control Protocol) Socket

•

UDP (User Datagram Protocol) Socket

d. Java Networking e. Rekayasa Perangkat Lunak

3.2

•

Analisis Kebutuhan (Requirement Analysis)

•

Perancangan (Design)

•

Implementasi

•

Pengujian (Testing) Analisis Kebutuhan (Requirement Analysis) Analisis kebutuhan bertujuan untuk mendapatkan semua kebutuhan yang

diperlukan dari sistem yang akan dibangun. Metode analisis yang digunakan adalah Object Oriented Analysis dengan menggunakan bahasa pemodelan UML (Unified Modeling Language). Use Case Diagram digunakan untuk mendeskripsikan kebutuhankebutuhan dan

fungsionalitas sistem dari perspektif end-user. Analisis kebutuhan

dilakukan dengan mengidentifikasi semua kebutuhan (requirements) sistem (multiplayer 29

tank game) yang kemudian akan dimodelkan dalam use case diagram. Use Case Diagram multiplayer tank game terbagi menjadi 2 buah subsistem yaitu, subsistem game server dan subsistem game client. Pada skripsi ini akan dijelaskan use case–use case untuk subsistem game server. Use case-use case untuk subsistem game client akan dibahas pada skripsi yang berjudul “Pengembangan 2D Game Client Untuk Multiplayer Tank Game Menggunakan Teknologi Java” oleh Murti Daryandono (Teknik Elektro Universitas Brawijaya, 2008). 3.3

Perancangan (Design) Perancangan aplikasi dilakukan setelah semua kebutuhan sistem didapatkan

melalui tahap analisis kebutuhan. Perancangan aplikasi berdasarkan Object Oriented Analysis dan Object Oriented Design yaitu menggunakan pemodelan UML (Unified Modeling

Language).

Perancangan

subsistem

game

server

dilakukan

dengan

mengidentifikasi kelas-kelas dan interface-interface yang dibutuhkan yang dimodelkan dalam class diagram. Hubungan interaksi antar elemen (objek) yang telah diidentifikasi, dimodelkan dalam Sequence Diagram yang menggambarkan interaksi antar objek yang disusun dalam urutan waktu. Perancangan game server ini secara garis besar meliputi :

3.4

•

Proses discovery untuk menemukan server-server permainan yang aktif.

•

Proses creating game session, joining game session, dan ending game session.

•

Pengiriman dan penerimaan data (pengolahan data yang diterima).

•

Manajemen pemain-pemain dalam multiplayer game. Implementasi Implementasi aplikasi dilakukan dengan mengacu kepada perancangan aplikasi.

Implementasi perangkat lunak dilakukan dengan menggunakan bahasa pemrograman berorientasi objek yaitu menggunakan bahasa pemrograman Java (Java Standard Edition). Implementasi subsistem game server ini akan diintegrasikan dengan subsistem game client yang dihasilkan dari skripsi yang berjudul “Pengembangan 2D Game Client Untuk Multiplayer Tank Game Menggunakan Teknologi Java” oleh Murti Daryandono (Teknik Elektro Universitas Brawijaya, 2008).

30

3.5

Pengujian dan Analisis Pengujian perangkat lunak pada skripsi ini dilakukan agar dapat menunjukkan

bahwa perangkat lunak telah mampu bekerja sesuai dengan spesifikasi dari kebutuhan yang melandasinya. Pengujian yang dilakukan meliputi Pengujian performa sistem meliputi nilai throughput data yang dipengaruhi oleh banyaknya client serta pengujian perangkat lunak. Strategi pengujian perangkat lunak yang digunakan yaitu pengujian unit (unit testing), pengujian integrasi (integration testing), dan pengujian validasi (validation testing). Dan teknik atau metode pengujian yang digunakan adalah metode pengujian white box dan black box. Pada skripsi ini dilakukan pengujian perangkat lunak untuk subsistem game server. Pengujian perangkat lunak subsistem game client akan dibahas pada skripsi yang berjudul “Pengembangan 2D Game Client Untuk Multiplayer Tank Game Menggunakan Teknologi Java” oleh Murti Daryandono (Teknik Elektro Universitas Brawijaya, 2008). Pengujian dimulai dari pengujian unit, kemudian dilanjutkan dengan pengujian integrasi, dan berakhir pada pengujian validasi. Pada tahap pengujian unit digunakan metode pengujian white box dengan teknik basis path, sedangkan pada pengujian integrasi digunakan teknik white box, dilakukan dengan mengambil input kelas yang lolos pada pengujian unit, kemudian kelas yang lolos pada pengujian unit diintegrasikan melalui kelas kontrol untuk diujikan. Pada tahap pengujian validasi digunakan teknik black-box. 3.6

Pengambilan Kesimpulan Pengambilan kesimpulan dilakukan setelah semua tahapan perancangan,

implementasi dan pengujian sistem aplikasi telah selesai dilakukan. Kesimpulan diambil dari hasil pengujian dan analisis terhadap sistem yang dibangun. Tahap terakhir dari penulisan adalah saran yang dimaksudkan untuk memperbaiki kesalahan-kesalahan yang terjadi dan menyempurnakan penulisan serta untuk memberikan pertimbangan atas pengembangan aplikasi selanjutnya.

31

BAB IV PERANCANGAN Bab ini membahas mengenai perancangan perangkat lunak. Perancangan yang dilakukan meliputi dua tahap. Proses analisis kebutuhan dilakukan pada tahap pertama dan tahap yang kedua adalah proses perancangan perangkat lunak. Tahap analisis kebutuhan terdiri dari dua langkah yaitu membuat daftar kebutuhan user dan menggunakan pemodelan use case diagram untuk menggambarkan kebutuhan tersebut. Proses perancangan perangkat lunak mempunyai dua tahap, yaitu perancangan umum dan

perancangan detail subsistem game server.

Perancangan umum menggambarkan relasi antar paket (package) dan klas (class) sebagai pemodelan subsistem game server keseluruhan. Perancangan detail menggunakan class diagram dan sequence diagram sebagai pemodelan perangkat lunak. 4.1

Analisis Kebutuhan (Requirement Analysis) Proses analisis kebutuhan mengambil acuan dari gameplay dari

multiplayer tank game dan hasil pengumpulan, pemahaman dan penetapan kebutuhan-kebutuhan (requirements) yang ingin didapatkan oleh pengguna. Pada analisis kebutuhan ini diawali dengan identifikasi aktor-aktor yang terlibat dalam game, penjabaran daftar kebutuhan dan kemudian memodelkannya ke dalam suatu diagram use case. Analisis kebutuhan ini ditujukan untuk menggambarkan kebutuhan-kebutuhan yang harus disediakan oleh sistem agar dapat memenuhi kebutuhan pengguna sesuai gameplay yang dibuat. 4.1.1

Identifikasi Aktor Tahap ini mempunyai tujuan untuk melakukan identifikasi terhadap

aktor-aktor yang akan berinteraksi dengan sistem atau terlibat dalam game. Tabel 4.1 memperlihatkan empat buah aktor beserta penjelasannya masing-masing yang merupakan hasil dari proses identifikasi aktor. Tabel 4.1 Deskripsi Aktor Aktor

Deskripsi Aktor

Player

Player merupakan aktor pengguna yang

32

belum aktif dalam sebuah sesi

permainan. Valid Player

Valid Player merupakan aktor pengguna yang aktif dalam sebuah sesi permainan. Joiner merupakan aktor pengguna yang berhasil bergabung ke sebuah sesi

Joiner

permainan dengan cara melakukan koneksi ke sebuah game server. Creator

Creator merupakan aktor pengguna yang berhasil menciptakan sebuah sesi permainan dan mengaktifkan sebuah game server.

Sumber : Analisis Kebutuhan

4.1.2

Daftar Kebutuhan Daftar kebutuhan ini terdiri dari sebuah kolom yang menguraikan

kebutuhan yang harus disediakan oleh sistem, dan pada kolom yang lain akan menunjukkan nama use case yang akan menyediakan fungsionalitas masingmasing kebutuhan tersebut. Daftar kebutuhan fungsional dan non fungsional keseluruhan sistem ditunjukkan pada Tabel 4.2. Tabel 4.2 Daftar kebutuhan fungsional dan non fungsional ID

Requirements

Aktor

Nama Use Case

F01

Sistem harus menyediakan antarmuka untuk menampilkan proses memuat konfigurasi permainan

Player

Menampilkan Menu Loading

F02

Sistem harus menyediakan antarmuka untuk menampilkan berbagai menu utama permainan

Player

Menampilkan Menu Utama

F03

Sistem harus menyediakan antarmuka Help untuk memberi bantuan keterangan permainan kepada pemain

Player

Menampilkan Menu Help

F04

Sistem harus menyediakan antarmuka Credits untuk memberi keterangan mengenai teknologi dan pembuat permainan

Player

Menampilkan Menu Credits

F05

Sistem harus menyediakan antarmuka Options untuk pemain yg ingin mengatur konfigurasi yg digunakan selama permainan berlangsung

Player

Menampilkan Menu Options

F06

Sistem harus menyediakan antarmuka Join Game untuk pemain yang menginginkan bergabung pada sesi permainan yang telah ada

Player

Menampilkan Game

F07

Sistem harus menyediakan antarmuka Create Game untuk pemain yang ingin menciptakan sesi permainan baru

Player

Menampilkan Game

33

Menu

Menu

Join

Create

F08

Sistem harus menyediakan proses untuk mencari sesi-sesi permainan yang aktif.

Player

Mencari Sesi Permainan Yang Aktif.

F09

Sistem harus menyediakan proses untuk bergabung ke sesi permainan yang aktif dan melakukan koneksi ke sebuah game server.

Player

Bergabung Permainan.

F10

Sistem harus menyediakan proses untuk membuat sebuah sesi permainan dan mengaktifkan sebuah game server.

Player

Membuat Sesi Permainan.

F11

Sistem harus menyediakan komponen untuk memberi keterangan mengenai fungsi keypad permainan

Valid Player

Menampilkan Key Info Box

F12

Sistem harus menyediakan komponen untuk menampilkan pesan chat dari pemain lain

Valid Player

Menampilkan Chat Board

F13

Sistem harus menyediakan komponen untuk menampilkan flash message permainan

Valid Player

Menampilkan Flash Message

F14

Sistem harus menyediakan komponen untuk menampilkan system message board permainan

Valid Player

Menampilkan Message Board

F15

Sistem harus menyediakan komponen untuk menampilkan waktu permainan selama satu ronde

Valid Player

Menampilkan Round Timer

F16

Sistem harus menyediakan komponen untuk menampilkan radar yang dimiliki oleh pemain

Valid Player

Menampilkan Radar Pemain

F17

Sistem harus menyediakan komponen untuk menampilkan player bar yang berisi berbagai keterangan mengenai karakter pemain

Valid Player

Menampilkan Player Bar

F18

Sistem harus menyediakan komponen untuk menampilkan nilai yang dimiliki oleh pemain

Valid Player

Menampilkan Daftar Score

F19

Sistem harus menyediakan komponen untuk mengerakkan kamera pemain ketika berstatus tidak aktif

Valid Player

Menggerakkan Kamera

F20

Sistem harus menyediakan komponen untuk menerima pesan chat yang dituliskan oleh pemain

Valid Player

Menampilkan Kotak Chat

F21

Sistem harus menyediakan komponen dialog untuk mengganti tim dan mengganti tank

Valid Player

Menampilkan Dialog Ganti Tim dan Tank

F22

Sistem harus menyediakan komponen dialog untuk mengatur pilihan-pilihan yang terkait dengan permainan

Valid Player

Menampilkan Dialog Opsi

F23

Sistem harus menyediakan proses untuk menggerakkan badan tank dan menggerakkan meriam

Valid Player

Menggerakkan Tank

34

Dengan

Sesi

System

F24

Sistem harus menyediakan proses bagi pemain untuk menembakkan rudal

Valid Player

Menembakkan Rudal

F25

Sistem harus menyediakan proses bagi pemain untuk menembakkan senjata mesin

Valid Player

Menembakkan Senjata Mesin

F26

Sistem harus menyediakan proses untuk mengirimkan pesan chat pemain lokal.

Valid Player

Mengirimkan Chat

F27

Sistem harus meyediakan proses untuk menerima pesan chat dari remote player.

Valid Player

Menerima Chat

F28

Sistem harus menyediakan proses untuk mengirimkan notifikasi tentang update tim dan tank pemain lokal.

Valid Player

Mengirimkan Notifikasi Update Tim dan Tank

F29

Sistem harus menyediakan proses untuk menerima notifikasi tentang update tim dan tank dari remote player.

Valid Player

Menerima Notifikasi Tim dan Tank

F30

Sistem harus menyediakan proses untuk mengirimkan notifikasi tentang update nama pemain lokal.

Valid Player

Mengirimkan Notifikasi Update Nama Pemain

F31

Sistem harus menyediakan proses untuk menerima notifikasi tentang update nama pemain dari remote player.

Valid Player

Menerima Notifikasi Nama Pemain

F32

Sistem harus menyediakan proses untuk mengirimkan posisi tank pemain lokal.

Valid Player

Mengirimkan Posisi Tank

F33

Sistem harus menyediakan proses untuk menerima posisi tank dari remote player.

Valid Player

Menerima Update Posisi Tank

F34

Sistem harus menyediakan proses untuk mengirimkan status ketika pemain lokal menembakkan senjata.

Valid Player

Mengirimkan Fire State

F35

Sistem harus menyediakan proses untuk menerima status ketika remote player menembakkan senjata.

Valid Player

Menerima Fire State

F36

Sistem harus menyediakan proses untuk menerima notifikasi tentang pemain yang keluar dari sesi permainan.

Valid Player

Menerima Notifikasi Pemain Yang Keluar

F37

Sistem harus menyediakan proses untuk menerima notifikasi tentang pemain baru.

Valid Player

Menerima Notifikasi Pemain Baru

Sistem menyediakan komponen bagi game server untuk mengganti peta permainan

Creator

Menampilkan Peta

Sistem menyediakan komponen dialog bagi game server untuk mengkonfirmasi mengakhiri sesi permainan

Creator

Menampilkan Konfirmasi Mengakhiri Sesi Permainan

F38

F39

35

Dialog

Update

Update

Ganti

F40

Sistem harus menyediakan proses untuk menghentikan ronde permainan yang berlangsung dan memulai ronde permainan yang baru.

Creator

Memperbarui Ronde

F41

Sistem harus menyediakan proses untuk mengulangi ronde permainan yang sedang berlangsung.

Creator

Mengulangi Ronde

F42

Sistem harus menyediakan proses untuk mengirimkan notifikasi pergantian peta permainan kepada semua joiner.

Creator

Mengirimkan Notifikasi Ganti Peta

F43

Sistem harus menyediakan proses kepada creator untuk mengakhiri sesi permainan dan mematikan game server.

Creator

Mengakhiri Sesi Permainan

F44

Sistem harus menyediakan proses untuk mengirimkan status permainan.

Creator

Mengirimkan Notifikasi Status Permainan

F45

Sistem harus menyediakan komponen dialog untuk mengkonfirmasi keluar dari sesi permainan

Joiner

Menampilkan Konfirmasi Keluar Dari Sesi Permainan

F46

Sistem harus menyediakan proses kepada joiner untuk meninggalkan sesi permainan dan melakukan diskoneksi dari game server.

Joiner

Meninggalkan Sesi Permainan

F47

Sistem harus menyediakan proses untuk menerima notifikasi tentang pergantian peta permainan dari creator.

Joiner

Menerima Notifikasi Ganti Peta

F48

Sistem harus menyediakan proses untuk menerima notifikasi tentang status permainan.

Joiner

Menerima Notifikasi Permainan

N01

Sistem harus dapat melayani pemain dengan jumlah maksimal 10 pemain dengan nilai rata-rata frame per second (fps) lebih dari sama dengan 60 fps.

--

--

Status

Sumber : Analisis Kebutuhan

4.1.3

Diagram Use Case Kebutuhan-kebutuhan fungsional yang diperlukan oleh pengguna dan

harus disediakan oleh sistem akan dimodelkan pada diagram use case. Secara keseluruhan sistem ini mempunyai 48 buah use case yang dikelompokkan menjadi 2 buah subsistem yaitu, subsistem game client dan subsistem game server. Pada subsistem game client terdapat 25 buah use case yaitu, use case Menampilkan Menu Loading, Menampilkan Menu Utama, Menampilkan Menu Help, Menampilkan Menu Credits, Menampilkan Menu Options, Menampilkan Menu Join Game, Menampilkan Menu Create Game, Menampilkan Key Info Box,

36

Menampilkan Chat Board, Menampilkan Flash Message, Menampilkan System Message Board, Menampilkan Round Timer, Menampilkan Radar Pemain, Menampilkan Player Bar, Menampilkan Daftar Score, Menggerakkan Kamera, Menampilkan Kotak Chat, Menampilkan Dialog Ganti Tim dan Tank, Menampilkan Dialog Opsi, Menggerakkan Tank,

Menembakkan Rudal,

Menembakkan Senjata Mesin, Menampilkan Dialog Ganti Peta, Menampilkan Konfirmasi Mengakhiri Sesi Permainan, dan Menampilkan Konfirmasi Keluar Dari Sesi Permainan. Pada subsistem game server terdapat 23 buah use case yaitu, use case Mencari Sesi Permainan Yang Aktif, Bergabung Dengan Sesi Permainan,

Membuat Sesi Permainan, Mengirimkan Chat, Menerima Chat,

Mengirimkan Notifikasi Update Tim dan Tank, Menerima Notifikasi Update Tim dan Tank, Mengirimkan Notifikasi Update Nama Pemain, Menerima Notifikasi Update Nama Pemain, Mengirimkan Posisi Tank, Menerima Update Posisi Tank, Mengirimkan Fire State, Menerima Fire State, Memperbarui Ronde, Mengulangi Ronde, Mengirimkan Notifikasi Ganti Peta, Mengakhiri Sesi Permainan, Mengirimkan Notifikasi Status Permainan, Meninggalkan Sesi Permainan, Menerima Notifikasi Ganti Peta, Menerima Notifikasi Pemain Yang Keluar, Menerima Notifikasi Pemain Baru, dan Menerima Notifikasi Status Permainan. Pada diagram use case ini terdapat 4 aktor yaitu player, valid player, creator, dan joiner. Pada skripsi ini dibahas use case - use case yang berada dalam subsistem game server. Sedangkan use case – use case yang berada dalam subsistem game client dibahas dalam skripsi yang berjudul Pengembangan 2D Game Client Untuk Multiplayer Tank Game Menggunakan Teknologi Java” oleh Murti Daryandono (Teknik Elektro Universitas Brawijaya, 2008). Gambar 4.1 merupakan use case diagram keseluruhan sistem.

37

Gambar 4.1 Diagram use case sistem Sumber: Analisis Kebutuhan

38

4.1.4

Skenario Use Case Secara lebih mendetail, masing-masing use case yang terdapat pada

diagram use case, dijabarkan dalam skenario use case. Di dalam skenario use case, akan diberikan uraian nama use case, aktor yang berhubungan dengan use case tersebut, tujuan dari use case, deskripsi global tentang use case, pra-kondisi yang harus dipenuhi dan pos-kondisi yang diharapkan setelah berjalannya fungsional use case. Selain itu juga akan diberikan ulasan yang berkaitan dengan tanggapan dari sistem atas suatu aksi yang diberikan oleh aktor (aliran utama), serta kejadian alternatif yang akan terjadi jika suatu kondisi tidak bisa terpenuhi (aliran alternatif). Tabel 4.3 merupakan skenario use case Mencari Sesi Permainan Yang Aktif. Tabel 4.3 Skenario use case Mencari Sesi Permainan Yang Aktif. Use case

Mencari Sesi Permainan Yang Aktif

Aktor

Player

Tujuan

Mencari sesi - sesi permainan yang aktif dalam LAN (Local Area Network). Untuk mencari sesi permainan yang aktif, player terlebih dahulu harus masuk

Deskripsi

ke menu join game. Kemudian menekan tombol “scan server” untuk memulai proses.

Pra-kondisi

Aktor membuka menu join game.

Pos-kondisi

Di server list pada menu join game muncul daftar sesi-sesi permainan yang aktif. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem

1. Pada menu join game, player menekan

2. Melakukan

tombol “scan server” untuk memulai proses

permainan

pencarian sesi permainan.

pencarian berupa ip address server,

proses dan

pencarian

sesi

menampilkan

hasil

nama server, dan jumlah pemain yang aktif di server list.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk bergabung dengan sesi permainan. Kebutuhan tersebut direpresentasikan oleh use case Bergabung Dengan Sesi Permainan. Tabel 4.4. merupakan skenario use case Bergabung Dengan Sesi Permainan. Tabel 4.4 Skenario use case Bergabung Dengan Sesi Permainan. Use case

Bergabung Dengan Sesi Permainan

Aktor

Player

39

Tujuan

Bergabung dengan sesi permainan yang aktif. Untuk bergabung dengan sesi permainan yang aktif, player terlebih dahulu

Deskripsi

harus masuk ke menu join game dan mengisikan ip address server, password sesi (opsional) dan memilih tim dan tank.

Pra-kondisi Pos-kondisi

Aktor membuka menu join game. Player berubah status menjadi valid player dan joiner. Dan Kemudian masuk ke ingame state. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem

1. Pada menu join game, player mengisikan ip

2. Melakukan proses koneksi ke game

address server, password (opsional) dan

server dan menunggu jawaban dari

memilih tim dan tank. Kemudian menekan

game server dengan waktu timeout 1

tombol “Ok” untuk memulai proses koneksi ke

detik. Setelah mendapat jawaban bahwa

game server.

koneksi

berhasil

dari

game

server

kemudian status player tersebut berubah menjadi valid player dan joiner. Dan ditampilkan ingame state. Aliran Alternatif 1 : Eksepsi jika proses koneksi ke game server gagal. 1. Menampilkan

pernyataan

peringatan

kesalahan (alert) jika proses koneksi ke game server gagal. Kegagalan proses koneksi ini diakibatkan oleh ip address server

yang dimasukkan tidak valid,

password sesi tidak valid, dan jumlah pemain telah mencapai jumlah maksimal.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk membuat sesi permainan. Kebutuhan tersebut direpresentasikan oleh use case Membuat Sesi Permainan. Tabel 4.5. merupakan skenario use case Membuat Sesi Permainan. Tabel 4.5 Skenario use case Membuat Sesi Permainan. Use case

Membuat Sesi Permainan

Aktor

Player

Tujuan

Membuat sebuah sesi permainan dan mengaktifkan sebuah game server. Untuk membuat sebuah sesi permainan, player terlebih dahulu harus masuk

Deskripsi

ke menu create game dan mengisikan password sesi (opsional) dan jumlah maksimal pemain dalam sebuah sesi permainan, memilih peta permainan, serta memilih tim dan tank.

Pra-kondisi

Aktor membuka menu create game.

Pos-kondisi

Player berubah status menjadi valid player dan creator. Dan kemudian masuk

40

ke ingame state. Aliran Utama Aksi dari Aktor

Tanggapan dari Sistem

1. Pada menu create game, player mengisikan

2. Melakukan

password

sesi

(opsional)

maksimal

pemain

pembuatan

sesi

jumlah

permainan dan sekaligus mengaktifkan

sesi

sebuah game server. Setelah game

permainan, memilih peta permainan, serta

server berhasil diaktifkan maka status

memilih tim dan tank. Kemudian menekan

player berubah menjadi valid player dan

tombol “Ok” untuk memulai proses.

creator. Dan ditampilkan ingame state.

dalam

dan

proses

sebuah

Aliran Alternatif 1 : Eksepsi jika gagal mengaktifkan game server. 1. Menampilkan

pernyataan

peringatan

kesalahan (alert) jika proses pengaktifan game

server

gagal.

Kegagalan

ini

disebabkan karena port yang digunakan game server

telah digunakan aplikasi

lain.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk mengirimkan chat. Kebutuhan tersebut direpresentasikan oleh use case Mengirimkan Chat. Tabel 4.6. merupakan skenario use case Mengirimkan Chat. Tabel 4.6 Skenario use case Mengirimkan Chat. Use case

Mengirimkan Chat

Aktor

Valid Player

Tujuan

Mengirimkan chat ke valid player yang lain.

Deskripsi

Untuk mengirimkan chat, valid player harus menampilkan kotak chat dan menuliskan isi chat.

Pra-kondisi

Aktor berada pada ingame state dan menulis chat.

Pos-kondisi

Pesan Chat terkirim melalui jaringan komputer. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem

1. Valid player menuliskan isi chat pada kotak

2. Melakukan proses pengiriman chat ke

chat. Kemudian menekan tombol keyboard

semua valid player.

“Enter”.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk menerima chat. Kebutuhan tersebut direpresentasikan

41

oleh use case Menerima Chat. Tabel 4.7. merupakan skenario use case Menerima Chat. Tabel 4.7 Skenario use case Menerima Chat. Use case

Menerima Chat

Aktor

Valid Player

Tujuan

Menerima dan mengolah pesan chat yang diterima dari valid player lainnya. Melakukan proses penerimaan pesan chat yang dikirimkan melalui jaringan

Deskripsi

komputer dan kemudian pesan chat akan disimpan dalam memory.

Pra-kondisi

Pesan chat masuk terdeteksi oleh sistem.

Pos-kondisi

Pesan chat berada dalam memory siap untuk dirender. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem 1. Sistem mendeteksi adanya pesan chat baru yang diterima, kemudian sistem menyimpan pesan chat tersebut ke dalam memory untuk dirender.

Aliran Alternatif 1 : Eksepsi jika penerimaan pesan chat gagal. 1. Sistem akan menangkap eksepsi yang terjadi ketika proses penerimaan pesan chat gagal. Eksepsi diakibatkan data pesan chat tidak valid.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk mengirimkan notifikasi update tim dan tank. Kebutuhan tersebut direpresentasikan oleh use case Mengirimkan Notifikasi Update Tim dan Tank. Tabel 4.8. merupakan skenario use case Mengirimkan Notifikasi Update Tim dan Tank. Tabel 4.8 Skenario use case Mengirimkan Notifikasi Update Tim dan Tank. Use case

Mengirimkan Notifikasi Update Tim dan Tank

Aktor

Valid Player

Tujuan

Memberitahukan kepada valid player yang lain tentang adanya update tim dan tank valid player. Untuk mengirimkan pesan notifikasi update tim dan tank, valid player harus

Deskripsi

memilih tim dan tank pada dialog ganti tim dan tank kemudian menekan tombol “Ok”.

Pra-kondisi

Aktor berada pada ingame state dan memilih tim dan tank.

Pos-kondisi

Pesan notifikasi update tim dan tank terkirim melalui jaringan komputer.

42

Aliran Utama Aksi dari Aktor

Tanggapan dari Sistem

1. Valid player memilih tim dan tank pada dialog

2. Melakukan proses pengiriman pesan

update tim dan tank. Kemudian menekan

notifikasi update tim dan tank ke semua

tombol “Ok”.

valid player.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk menerima notifikasi update tim dan tank. Kebutuhan tersebut direpresentasikan oleh use case Menerima Notifikasi Update Tim dan Tank. Tabel 4.9. merupakan skenario use case Menerima Notifikasi Update Tim dan Tank. Tabel 4.9 Skenario use case Menerima Notifikasi Update Tim dan Tank. Use case

Menerima Notifikasi Update Tim dan Tank

Aktor

Valid Player

Tujuan

Melakukan proses penerimaan pesan notifikasi update tim dan tank.

Deskripsi

Melakukan proses penerimaan pesan notifikasi update tim dan tank dan kemudian dilakukan update tim dan tank valid player.

Pra-kondisi

Pesan notifikasi update tim dan tank masuk terdeteksi oleh sistem.

Pos-kondisi

Tim dan tank valid player diperbarui. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem 1. Sistem

mendeteksi

adanya

pesan

notifikasi update tim dan tank yang diterima, kemudian sistem melakukan update tim dan tank sesuai ID valid player. 2. Aliran Alternatif 1 : Eksepsi jika penerimaan pesan notifikasi update tim dan tank gagal 1. Sistem akan menangkap eksepsi yang terjadi ketika proses penerimaan pesan notifikasi update tim dan tank gagal. Eksepsi diakibatkan data pesan notifikasi update tim dan tank tidak valid.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk mengirimkan notifikasi update nama pemain. Kebutuhan tersebut direpresentasikan oleh use case Mengirimkan Notifikasi Update Nama

43

Pemain. Tabel 4.10. merupakan skenario use case Mengirimkan Notifikasi Update Nama Pemain. Tabel 4.10 Skenario use case Mengirimkan Notifikasi Update Nama Pemain. Use case

Mengirimkan Notifikasi Update Nama Pemain

Aktor

Valid Player Memberitahukan kepada valid player yang lain tentang adanya nama valid

Tujuan

player. Untuk mengirimkan pesan notifikasi update nama pemain, valid player harus

Deskripsi

melakukan update nama pemain pada dialog opsi kemudian menekan tombol “Ok”.

Pra-kondisi

Aktor berada pada ingame state dan mengubah namanya.

Pos-kondisi

Pesan notifikasi update nama pemain terkirim melalui jaringan komputer. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem

1. Valid player mengubah namanya pada dialog

2. Melakukan proses pengiriman pesan

opsi. Kemudian menekan tombol “Ok”.

notifikasi update nama pemain ke semua valid player.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk menerima notifikasi update nama pemain. Kebutuhan tersebut direpresentasikan oleh use case Menerima Notifikasi Update Nama Pemain. Tabel 4.11. merupakan skenario use case Menerima Notifikasi Update Nama Pemain. Tabel 4.11 Skenario use case Menerima Notifikasi Update Nama Pemain. Use case

Menerima Notifikasi Update Nama Pemain

Aktor

Valid Player

Tujuan

Melakukan proses penerimaan pesan notifikasi update nama pemain.

Deskripsi

Melakukan proses penerimaan pesan notifikasi update nama pemain dan kemudian dilakukan update nama valid player.

Pra-kondisi

Pesan notifikasi update nama pemain masuk terdeteksi oleh sistem.

Pos-kondisi

Nama valid player diperbarui. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem 1. Sistem

mendeteksi

adanya

pesan

notifikasi update tim nama pemain yang diterima, kemudian sistem melakukan update nama pemain sesuai ID valid player.

44

Aliran Alternatif 1 : Eksepsi jika penerimaan pesan notifikasi update nama pemain gagal 1. Sistem akan menangkap eksepsi yang terjadi ketika proses penerimaan pesan notifikasi update nama pemain gagal. Eksepsi diakibatkan data pesan notifikasi update nama pemain tidak valid.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk mengirimkan posisi tank. Kebutuhan tersebut direpresentasikan oleh use case Mengirimkan Posisi Tank. Tabel 4.12. merupakan skenario use case Mengirimkan Posisi Tank. Tabel 4.12 Skenario use case Mengirimkan Posisi Tank. Use case

Mengirimkan Posisi Tank

Aktor

Valid Player

Tujuan

Melakukan proses pengiriman posisi tank yang terbaru ke semua valid player. Untuk melakukan proses pengiriman posisi tank yang terbaru ke valid player

Deskripsi

yang lain, valid player menggerakkan tank terlebih dahulu.

Pra-kondisi

Aktor menggerakkan tank.

Pos-kondisi

Posisi tank terbaru terkirim lewat jaringan komputer. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem

1. Valid player menggerakkan tank.

2. Melakukan proses pengiriman posisi tank (x, y, body angle, turret angle) yang terbaru ke semua valid player.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk menerima update posisi tank. Kebutuhan tersebut direpresentasikan oleh use case Menerima Update Posisi Tank. Tabel 4.13. merupakan skenario use case Menerima Update Posisi Tank. Tabel 4.13 Skenario use case Menerima Update Posisi Tank. Use case

Menerima Update Posisi Tank

Aktor

Valid Player

Tujuan

Melakukan proses penerimaan pesan update posisi tank.

Deskripsi

Melakukan proses penerimaan pesan update posisi tank dan kemudian dilakukan update posisi tank valid player.

Pra-kondisi

Pesan update posisi tank masuk terdeteksi oleh sistem.

Pos-kondisi

Posisi tank valid player diperbarui.

45

Aliran Utama Aksi dari Aktor

Tanggapan dari Sistem 1. Sistem mendeteksi adanya pesan update posisi tank diterima, kemudian sistem melakukan update posisi tank (x, y, body angle, turret angle) sesuai ID valid player.

Aliran Alternatif 1 : Eksepsi jika penerimaan pesan update posisi tank gagal 1. Sistem akan menangkap eksepsi yang terjadi ketika proses penerimaan pesan update

posisi

diakibatkan

tank

kesalahan

gagal. format

Eksepsi pesan

update posisi tank.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah

kebutuhan

untuk

mengirimkan

fire

state.

Kebutuhan

tersebut

direpresentasikan oleh use case Mengirimkan Fire State. Tabel 4.14. merupakan skenario use case Mengirimkan Fire State. Tabel 4.14 Skenario use case Mengirimkan Fire State. Use case

Mengirimkan Fire State

Aktor

Valid Player Memberitahukan ke valid player yang lain bahwa tank dari seorang valid

Tujuan

player melakukan penembakan rudal atau senjata mesin. Untuk melakukan proses pengiriman pesan fire state, valid player melakukan

Deskripsi

penembakan rudal atau senjata mesin terlebih dahulu.

Pra-kondisi

Aktor menembakkan senjata mesin atau rudal.

Pos-kondisi

Pesan fire state terkirim lewat jaringan komputer. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem

1. Valid player menembakkan senjata mesin

2. Melakukan proses pengiriman fire state

atau rudal.

sesuai tipe tembakan yang dilakukan valid player (senjata mesin atau rudal) ke semua valid player.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah

kebutuhan

untuk

menerima

46

fire

state.

Kebutuhan

tersebut

direpresentasikan oleh use case Menerima Fire State. Tabel 4.15. merupakan skenario use case Menerima Fire State. Tabel 4.15 Skenario use case Menerima Fire State. Use case

Menerima Fire State

Aktor

Valid Player Melakukan proses penerimaan pesan fire state

Tujuan

(pesan notifikasi ketika

remote valid player menembakkan senjata mesin atau rudal). Melakukan proses penerimaan pesan fire state dan kemudian dilakukan aksi

Deskripsi

menembak oleh tank remote valid player.

Pra-kondisi

Pesan fire state masuk terdeteksi oleh sistem.

Pos-kondisi

Tank remote valid player menembakkan senjata. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem 1. Sistem mendeteksi adanya pesan fire state

(pesan notifikasi ketika remote

valid player menembakkan senjata mesin atau rudal) yang diterima, kemudian sistem memeriksa ID remote valid player untuk mengetahui remote valid player yang melakukan tembakan dan ID pesan untuk mengetahui tipe tembakan yang dilakukan

oleh

remote

valid

player,

tembakan senjata mesin atau rudal. Kemudian sistem membuat tank remote valid player menembakkan senjata.

Aliran Alternatif 1 : Eksepsi jika penerimaan pesan fire state gagal 1. Sistem akan menangkap eksepsi yang terjadi ketika proses penerimaan pesan fire state gagal. Eksepsi diakibatkan data pesan fire state tidak valid.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah

kebutuhan

untuk

memperbarui

ronde.

Kebutuhan

tersebut

direpresentasikan oleh use case Memperbarui Ronde. Tabel 4.16. merupakan skenario use case Memperbarui Ronde. Tabel 4.16 Skenario use case Memperbarui Ronde. Use case

Memperbarui Ronde

Aktor

Creator

47

Memperbarui ronde permainan yaitu dengan menghentikan ronde yang

Tujuan

berlangsung dan memulai ronde baru. Untuk memperbarui ronde permainan creator harus menekan tombol

Deskripsi

keyboard “N” terlebih dahulu.

Pra-kondisi

Aktor berada pada ingame state.

Pos-kondisi

Ronde permainan yang baru dimulai. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem

1. Creator menekan tombol keyboard “N” untuk

2. Mengentikan ronde permainan yang sedang berlangsung dan menghitung perolehan semua pemain. Dan kemudian memulai ronde permainan baru.

memperbarui ronde permainan.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk mengulangi ronde. Kebutuhan tersebut direpresentasikan oleh use case Mengulangi Ronde. Tabel 4.17. merupakan skenario use case Mengulangi Ronde. Tabel 4.17 Skenario use case Mengulangi Ronde. Use case

Mengulangi Ronde

Aktor

Creator

Tujuan

Mengulangi ronde permainan yang sedang berlangsung. Untuk mengulangi ronde permainan creator harus menekan tombol keyboard

Deskripsi

“R” terlebih dahulu.

Pra-kondisi

Aktor berada pada ingame state.

Pos-kondisi

Ronde permainan yang sedang berlangsung diulang. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem

1. Creator menekan tombol keyboard “R” untuk

2. Membatalkan

memperbarui ronde permainan.

semua

perolehan

nilai

pemain dan melakukan reset semua status pemain. Dan mengulangi ronde permainan yang sedang berlangsung.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk mengirimkan notifikasi ganti peta. Kebutuhan tersebut direpresentasikan oleh use case Mengirimkan Notifikasi Ganti Peta. Tabel 4.18. merupakan skenario use case Mengirimkan Notifikasi Ganti Peta. Tabel 4.18 Skenario use case Mengirimkan Notifikasi Ganti Peta. Use case

Mengirimkan Notifikasi Ganti Peta

Aktor

Creator

48

Tujuan

Memberitahukan kepada semua joiner bahwa peta permainan telah diganti. Untuk mengirimkan notifikasi ganti peta permainan, creator harus mengganti

Deskripsi

peta permainan pada dialog ganti peta terlebih dahulu.

Pra-kondisi

Aktor mengganti peta permainan pada dialog ganti peta.

Pos-kondisi

Pesan notifikasi ganti peta permainan terkirim lewat jaringan komputer. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem

1. Creator mengganti peta permainan pada

2. Melakukan proses pengiriman pesan

dialog ganti peta.

notifikasi ganti peta ke semua joiner.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk menerima notifikasi ganti peta. Kebutuhan tersebut direpresentasikan oleh use case Menerima Notifikasi Ganti Peta. Tabel 4.19. merupakan skenario use case Menerima Notifikasi Ganti Peta. Tabel 4.19 Skenario use case Menerima Notifikasi Ganti Peta. Use case

Menerima Notifikasi Ganti Peta

Aktor

Joiner

Tujuan

Melakukan proses penerimaan pesan notifikasi ganti peta.

Deskripsi

Melakukan proses penerimaan pesan notifikasi ganti peta dari game server atau creator. Dan kemudian dilakukan update ganti peta permainan.

Pra-kondisi

Pesan notifikasi ganti peta masuk terdeteksi oleh sistem.

Pos-kondisi

Peta permainan diperbarui. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem 1. Sistem

mendeteksi

notifikasi ganti peta ketika

sistem

yang

pesan

(pesan notifikasi

creator

permainan)

adanya

mengganti diterima,

melakukan

peta

kemudian

update

peta

permainan dan ronde baru dimulai. Aliran Alternatif 1 : Eksepsi jika penerimaan pesan notifikasi ganti peta gagal 1. Sistem akan menangkap eksepsi yang terjadi ketika proses penerimaan pesan notifikasi ganti peta gagal. Eksepsi diakibatkan data pesan notifikasi ganti peta tidak valid.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk mengakhiri sesi permainan. Kebutuhan tersebut

49

direpresentasikan oleh use case Mengakhiri Sesi Permainan. Tabel 4.20. merupakan skenario use case Mengakhiri Sesi Permainan. Tabel 4.20 Skenario use case Mengakhiri Sesi Permainan. Use case

Mengakhiri Sesi Permainan

Aktor

Creator Mengakhiri sesi permainan yang sedang berlangsung dan mematikan game

Tujuan

server. Untuk mengakhiri sesi permainan yang sedang berlangsung, creator harus

Deskripsi

menampilkan konfirmasi mengakhiri sesi permainan dan menekan tombol “Ok” terlebih dahulu.

Pra-kondisi Pos-kondisi

Aktor berada dalam ingame state dan menampilkan konfirmasi mengakhiri sesi permainan dan menekan tombol “Ok”. Sesi permainan diakhiri. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem

1. Creator menampilkan konfirmasi mengakhiri

2. Mengakhiri sesi permainan yang sedang

sesi permainan dan menekan tombol “Ok”

berlangsung

dan

mematikan

game

untuk mengakhiri sesi permainan.

server. Dan kemudian keluar dari ingame state ke menu create game.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk mengirimkan notifikasi status permainan. Kebutuhan tersebut direpresentasikan oleh use case Mengirimkan Notifikasi Status Permainan. Tabel 4.21. merupakan skenario use case Mengirimkan Notifikasi Status Permainan. Tabel 4.21 Skenario use case Mengirimkan Notifikasi Status Permainan. Use case

Mengirimkan Notifikasi Status Permainan

Aktor

Creator Mengirimkan pesan notifikasi status permainan ketika creator melakukan

Tujuan

update status permainan (memperbarui ronde, mengulangi ronde, atau mengakhiri sesi permainan). Proses pengiriman

Deskripsi

pesan

notifikasi status permainan ketika

creator

melakukan update status permainan (memperbarui ronde, mengulangi ronde, atau mengakhiri sesi permainan).

Pra-kondisi

Status permainan diperbarui.

Pos-kondisi

Pesan notifikasi update status permainan terkirim melalui jaringan komputer. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem

50

1. Creator melakukan update status permainan.

2. Melakukan proses pengiriman pesan notifikasi status permainan ke semua joiner.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk menerima notifikasi status permainan. Kebutuhan tersebut direpresentasikan oleh use case Menerima Notifikasi Status Permainan. Tabel 4.22. merupakan skenario use case Menerima Notifikasi Status Permainan. Tabel 4.22 Skenario use case Menerima Notifikasi Status Permainan. Use case

Menerima Notifikasi Status Permainan

Aktor

Joiner Melakukan proses penerimaan pesan notifikasi status penerimaan (pesan notifikasi ketika creator mengulangi ronde permainan, melakukan ronde

Tujuan

permainan yang baru , dan mengakhiri sesi permainan atau mematikan game server).

Deskripsi

Melakukan proses penerimaan pesan notifikasi status penerimaan. Dan kemudian dilakukan update status permainan.

Pra-kondisi

Pesan notifikasi status permainan masuk terdeteksi oleh sistem.

Pos-kondisi

Status permainan diperbarui. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem 1. Sistem mendeteksi adanya pesan notifikasi status permainan yang diterima. Kemudian sistem melakukan update status permainan (mengulangi ronde permainan, melakukan ronde permainan yang baru , dan keluar dari sesi permainan) sesuai dengan ID tipe pesan notifikasi status permainan yang diterima.

Aliran Alternatif 1 : Eksepsi jika penerimaan pesan notifikasi status permainan gagal 1. Sistem akan menangkap eksepsi yang terjadi ketika proses penerimaan pesan notifikasi status permainan gagal. Eksepsi diakibatkan data pesan notifikasi status permainan tidak valid.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk meninggalkan sesi permainan. Kebutuhan tersebut direpresentasikan oleh use case Meninggalkan Sesi Permainan. Tabel 4.23. merupakan skenario use case Meninggalkan Sesi Permainan.

51

Tabel 4.23 Skenario use case Meninggalkan Sesi Permainan. Use case

Meninggalkan Sesi Permainan

Aktor

Joiner

Tujuan

Meninggalkan sesi permainan dan melakukan diskoneksi dari game server.

Deskripsi

Pra-kondisi Pos-kondisi

Untuk meninggalkan sesi permainan, joiner harus menampilkan konfirmasi meninggalkan sesi permainan dan menekan tombol “Ok”. Aktor berada dalam ingame state dan menampilkan konfirmasi meninggalkan sesi permainan dan menekan tombol “Ok”. Aktor keluar dari sesi permainan. Aliran Utama

Aksi dari Aktor 1. Joiner

Tanggapan dari Sistem menampilkan

konfirmasi

2. Melakukan proses pengiriman pesan

meninggalkan sesi permainan dan menekan

permintaan keluar dari sesi permainan

tombol “Ok”.

dan melakukan diskoneksi dari game server.

Dan kemudian keluar dari

ingame state ke menu join game.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk menerima notifikasi pemain yang keluar. Kebutuhan tersebut direpresentasikan oleh use case Menerima Notifikasi Pemain Yang Keluar. Tabel 4.24. merupakan skenario use case Menerima Notifikasi Pemain Yang Keluar. Tabel 4.24 Skenario use case Menerima Notifikasi Pemain Yang Keluar. Use case

Menerima Notifikasi Pemain Yang Keluar

Aktor

Valid Player

Tujuan

Melakukan proses penerimaan pesan notifikasi pemain yang keluar dari sesi permainan. Melakukan proses penerimaan pesan notifikasi pemain yang keluar dari sesi

Deskripsi

permainan. Dan kemudian dilakukan penghapusan data valid player yang meninggalkan sesi permainan.

Pra-kondisi

Pos-kondisi

Pesan notifikasi pemain yang keluar dari sesi permainan masuk terdeteksi oleh sistem. Data valid player yang meninggalkan sesi permainan dihapus dan valid player lain yang masih aktif membaca pesan notifikasi pemain yang keluar di layar. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem 1. Sistem mendeteksi adanya pesan notifikasi pemain yang keluar dari sesi permainan yang diterima. Kemudian sistem menghapus data remote valid player sesuai ID remote valid player.

52

Aliran Alternatif 1 : Eksepsi jika penerimaan pesan notifikasi pemain yang keluar gagal 1. Sistem akan menangkap eksepsi yang terjadi ketika proses penerimaan pesan notifikasi pemain yang keluar gagal. Eksepsi diakibatkan data pesan notifikasi pemain yang keluar tidak valid.

Sumber : Analisis Kebutuhan

Kebutuhan fungsional selanjutnya yang harus disediakan oleh sistem adalah kebutuhan untuk menerima notifikasi pemain baru. Kebutuhan tersebut direpresentasikan oleh use case Menerima Notifikasi Pemain Baru. Tabel 4.25. merupakan skenario use case Menerima Notifikasi Pemain Baru. Tabel 4.25 Skenario use case Menerima Notifikasi Pemain Baru. Use case

Menerima Notifikasi Pemain Baru

Aktor

Joiner Melakukan proses penerimaan pesan notifikasi pemain baru yang bergabung

Tujuan

dalam sesi permainan. Melakukan proses penerimaan pesan notifikasi pemain baru yang bergabung

Deskripsi

dalam sesi permainan. Dan kemudian melakukan penambahan data valid player baru.

Pra-kondisi Pos-kondisi

Pesan notifikasi pemain baru masuk terdeteksi oleh sistem. Data valid player yang baru ditambahkan dan valid player lain yang masih aktif membaca pesan notifikasi pemain baru di layar. Aliran Utama

Aksi dari Aktor

Tanggapan dari Sistem 1. Sistem mendeteksi adanya pesan notifikasi pemain baru yang bergabung dalam sesi permainan. Kemudian sistem melakukan penambahan data valid player.

Aliran Alternatif 1 : Eksepsi jika penerimaan pesan notifikasi pemain baru gagal 1. Sistem akan menangkap eksepsi yang terjadi ketika proses penerimaan pesan notifikasi pemain baru gagal. Eksepsi diakibatkan data pesan notifikasi pemain baru tidak valid.

Sumber : Analisis Kebutuhan

4.2

Perancangan Perangkat Lunak Perancangan perangkat lunak dilakukan dalam dua tahap yaitu,

perancangan umum dan perancangan detail subsistem game server. Sedangkan perancangan umum dan perancangan detail subsistem game client dibahas dalam

53

skripsi yang berjudul “Pengembangan 2D Game Client Untuk Multiplayer Tank Game Menggunakan Teknologi Java” oleh Murti Daryandono (Teknik Elektro Universitas Brawijaya, 2008). Perancangan perangkat lunak pada skripsi ini menggunakan pendekatan desain berorientasi objek yang direpresentasikan dengan menggunakan UML (Unified Modeling Language). Pada proses desain dilakukan identifikasi terhadap klas-klas yang dibutuhkan yang dimodelkan dalam class diagram dan hubungan interaksi antar elemen (objek) yang telah diidentifikasi, dimodelkan dalam sequence diagram. 4.2.1

Perancangan Umum Perancangan umum terdiri dari perancangan umum subsistem game

server dan model komunikasi data pada multiplayer tank game . Perancangan umum subsistem game server menggambarkan relasi antar paket (package) dan klas (class) sebagai pemodelan subsistem game server secara keseluruhan. Model komunikasi data pada multiplayer tank game menjelaskan mengenai model komunikasi data yang digunakan dalam multiplayer tank game. 4.2.1.1

Model Komunikasi Data Pada Multiplayer Tank Game Sebelum melakukan perancangan subsistem game server, dilakukan

pemilihan model komunikasi data pada multiplayer tank game. Model komunikasi data yang dilakukan adalah one-to-many communication atau many-to-one communication. Untuk melakukan komunikasi ini ada dua cara yang digunakan yaitu multicast transmission dan server message exploding [ARO-08]. Multicast transmission melakukan proses komunikasi tersebut pada level fisik. Pada server message exploding, data yang diterima oleh game server akan dikirimkan kembali ke game client - game client yang lain.

Dalam multiplayer tank game, multicast

transmission hanya digunakan untuk proses discovery server-server permainan yang aktif. Sedangkan server message exploding digunakan untuk sinkronisasi data antar pemain . Implementasi multicast transmission dan server message exploding yang digunakan dalam multiplayer tank game menggunakan protokol UDP. Gambar 4.2 menjelaskan perbedaan multicast transmission dan server message exploding.

54

Gambar 4.2 Multicast transmission vs. server message exploding. Sumber: [ARO-08]

4.2.1.2

Perancangan Umum Subsistem Game Server Perancangan umum subsistem game server menggambarkan relasi antar

paket (package) dan klas (class) sebagai pemodelan subsistem secara keseluruhan. Subsistem game server mempunyai 27 buah klas yang dikelompokkan menjadi 3

55

buah

paket

yaitu

paket

net.java.dev.boombat.multiplayer,

net.java.dev.boombat.multiplayer.core,

dan

net.java.dev.boombat.multiplayer.message. Relasi antar paket yang digunakan untuk subsistem game server dapat dilihat pada gambar 4.3.

Gambar 4.3 Package Diagram. Sumber: Perancangan

Relasi antar klas yang digunakan untuk subsistem game server dapat dilihat pada gambar 4.4.

56

Gambar 4.4 Relasi antar klas. Sumber: Perancangan

4.2.2

Perancangan Detail Perancangan detail menggunakan diagram klas (class diagram) dan

diagram sekuensial (sequence diagram) sebagai pemodelan perangkat lunak. Perancangan detail menjelaskan mengenai

pola hubungan antar komponen-

komponen detail (klas dan objek) sehingga mampu membentuk sebuah fungsi yang mampu memberikan pelayanan terhadap kebutuhan pengguna. 4.2.2.1

Diagram Klas (Class Diagram) Diagram klas memberikan gambaran pemodelan elemen-elemen klas

yang membentuk sebuah sistem perangkat lunak mulai dari atribut-atribut serta method-methodnya dan hubungannya dengan klas-klas lain dalam sebuah sistem.

57

Pada subsistem ini terdapat sejumlah klas yang saling membentuk relasi. Klasklas yang akan membangun subsistem ini dikelompokkan pada beberapa paket yaitu

paket

net.java.dev.boombat.multiplayer,

net.java.dev.boombat.multiplayer.core, net.java.dev.boombat.multiplayer.message.

Paket

net.java.dev.boombat.multiplayer terdiri dari 1 buah klas yaitu klas Manager. Atribut dan operasi dari masing-masing klas digambarkan dalam diagram klas pada Gambar 4.5.

Gambar 4.5 Diagram klas anggota paket net.java.dev.boombat.multiplayer. Sumber: Perancangan

Paket net.java.dev.boombat.multiplayer.core terdiri dari 10 buah klas yaitu klas Announcer, Client, ClientHandler, Finder, GameSession, Handler, Host, HostHandler, SecurityFilter, dan Util. Atribut dan operasi dari masingmasing klas digambarkan dalam diagram klas pada Gambar 4.6.

58

Gambar 4.6 Diagram klas anggota paket net.java.dev.boombat.multiplayer.core. Sumber: Perancangan

59

Paket net.java.dev.boombat.multiplayer.core terdiri dari 16 buah klas yaitu klas AddNewPlayerMsg, ChangePlayerNameMsg, ChangeTeamMsg, ChatMsg, FireBulletMsg, FireRocketMsg, InvalidLoginMsg, KeepAliveMsg, LeaveGameReqMsg, SessionFlagMsg,

LoginReqMsg,

SwitchMapMsg,

Message,

TankPositionMsg,

RemovePlayerMsg, dan

ValidLoginMsg.

Atribut dan operasi dari masing-masing klas digambarkan dalam diagram klas pada Gambar 4.7.

Gambar 4.7 Diagram klas anggota paket net.java.dev.boombat.multiplayer.message. Sumber: Perancangan

4.2.2.2

Diagram Sekuensial (Sequence Diagram) Pemodelan aliran jalannya proses interaksi antar objek atau klas yang

disusun berdasarkan urutan waktu ditunjukkan oleh sequence diagram. Sequence diagram digunakan untuk menggambarkan skenario atau rangkaian langkahlangkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan

60

output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan. Diagram sekuensial (sequence diagram) disusun dengan mengambil acuan pada use case dan klas-klas yang membentuk fungsionalitas yang digambarkan pada use case tersebut. •

Diagram Sekuensial Bergabung Dengan Sesi Permainan Gambar 4.8 merupakan diagram sekuensial Bergabung Dengan Sesi

Permainan. Diagram sekuensial ini menggambarkan interaksi ketika player melakukan koneksi ke game server atau sesi permainan yang sedang aktif .

Gambar 4.8 Diagram Sekuensial Bergabung Dengan Sesi Permainan. Sumber: Perancangan

61

•

Diagram Sekuensial Membuat Sesi Permainan Gambar 4.9 merupakan diagram sekuensial Membuat Sesi Permainan.

Diagram sekuensial ini menggambarkan interaksi ketika player membuat sebuah sesi permainan dan mengaktifkan sebuah game server.

Gambar 4.9 Diagram Sekuensial Membuat Sesi Permainan. Sumber: Perancangan

62

•

Diagram Sekuensial Mengirimkan Posisi Tank Gambar 4.10 merupakan diagram sekuensial Mengirimkan Posisi

Tank. Diagram sekuensial ini menggambarkan interaksi proses pengiriman posisi tank pemain.

Gambar 4.10 Diagram Sekuensial Mengirimkan Posisi Tank. Sumber: Perancangan

•

Diagram Sekuensial Menerima Update Posisi Tank Gambar 4.11 merupakan diagram sekuensial Menerima Update Posisi

Tank. Diagram sekuensial ini menngambarkan interaksi proses penerimaan posisi tank pemain.

63

Gambar 4.11 Diagram Sekuensial Menerima Update Posisi Tank. Sumber: Perancangan

•

Diagram Sekuensial Mengirimkan Fire State Gambar 4.12 merupakan diagram sekuensial Mengirimkan Fire State.

Diagram sekuensial ini menggambarkan proses pengiriman pesan fire state.

Gambar 4.12 Diagram Sekuensial Mengirimkan Fire State. Sumber: Perancangan

64

•

Diagram Sekuensial Menerima Fire State Gambar 4.13 merupakan diagram sekuensial Menerima Fire State.

Diagram sekuensial ini menggambarkan interaksi proses penerimaan fire state.

Gambar 4.13 Diagram Sekuensial Menerima Fire State. Sumber: Perancangan

•

Diagram Sekuensial Mengirimkan Notifikasi Status Permainan Gambar 4.14 merupakan diagram sekuensial Mengirimkan Notifikasi

Status Permainan. Diagram sekuensial ini menggambarkan interaksi proses pengiriman pesan status permainan.

Gambar 4.14 Diagram Sekuensial Mengirimkan Notifikasi Status Permainan. Sumber: Perancangan

65

•

Diagram Sekuensial Menerima Notifikasi Status Permainan Gambar 4.15 merupakan diagram sekuensial Menerima Notifikasi

Permainan. Diagram sekuensial ini menggambarkan interaksi proses penerimaan pesan status permainan.

Gambar 4.15 Diagram Sekuensial Menerima Notifikasi Status Permainan. Sumber: Perancangan

•

Diagram Sekuensial Mengakhiri Sesi Permainan Gambar 4.16 merupakan diagram sekuensial Mengakhiri Sesi

Permainan. Diagram sekuensial ini menggambarkan interaksi ketika creator mengakhiri sebuah sesi permainan.

Gambar 4.16 Diagram Sekuensial Mengakhiri Sesi Permainan. Sumber: Perancangan

66

•

Diagram Sekuensial Meninggalkan Sesi Permainan Gambar 4.17 merupakan diagram sekuensial Meninggalkan Sesi

Permainan. Diagram sekuensial ini menggambarkan interaksi ketika joiner meninggalkan sebuah sesi permainan.

Gambar 4.17 Diagram Sekuensial Meninggalkan Sesi Permainan. Sumber: Perancangan

67

BAB V IMPLEMENTASI Pada bab ini dibahas mengenai implementasi perangkat lunak berdasarkan hasil yang telah didapatkan dari analisis kebutuhan dan proses perancangan perangkat lunak dibuat. Pembahasan terdiri dari penjelasan tentang spesifikasi subsistem, batasan-batasan dalam implementasi, implementasi tiap klas pada file program, implementasi algoritma, dan beberapa kendala dalam implementasi subsistem game server. Sedangkan implementasi subsistem game client dibahas dalam skripsi yang berjudul “Pengembangan 2D Game Client Untuk Multiplayer Tank Game Menggunakan Teknologi Java”

oleh Murti

Daryandono (Teknik Elektro Universitas Brawijaya, 2008). 5.1

Spesifikasi Subsistem Hasil analisis kebutuhan dan perancangan perangkat lunak yang telah

diuraikan pada Bab 4 menjadi acuan untuk melakukan implementasi menjadi sebuah subsistem game server yang dapat berfungsi sesuai dengan kebutuhan. Spesifikasi subsistem diimplementasikan pada spesifikasi perangkat keras dan perangkat lunak 5.1.1

Spesifikasi Perangkat Keras Pengembangan subsistem game server menggunakan sebuah komputer

dengan spesifikasi perangkat keras yang dijelaskan pada Tabel 5.1. Tabel 5.1 Spesifikasi perangkat keras komputer Nama Komponen Prosesor Memori (RAM) Hardisk Mother Board Kartu Grafis

5.1.2

Spesifikasi Intel (R) Pentium(R) M 1,60 GHz 1,24 GB Fujitsu MHV2060AH, kapasitas 60 GB, 5400 rpm ANOTE Centurion Mobile Intel(R) 915GM/GMS, 910 Express Sumber: Implementasi

Spesifikasi Perangkat Lunak Pengembangan subsistem game server menggunakan perangkat lunak

dengan spesifikasi yang dijelaskan pada Tabel 5.2.

68

Tabel 5.2 Spesifikasi perangkat lunak komputer Sistem operasi Bahasa pemrograman Tools pemrograman Lingkungan pemrograman IDE (Integrated Development E i )

5.2

Microsoft Windows Professional version 2002 Service Pack 2 Java JDK 1.6.0_02 Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0_06) , Apache MINA Framework 2.00-M3 Netbeans IDE 6.1 Sumber: Implementasi

Batasan-Batasan Implementasi Beberapa batasan dalam mengimplementasikan subsistem adalah

sebagai berikut: 1.

Game server dirancang untuk dijalankan dalam lingkungan LAN (Local Area Network).

2.

Game server bertipe listen server.

3.

Game server dan game client diintegrasikan menjadi multiplayer tank game yang berbasiskan Java.

4.

Implementasi yang dihasilkan dari sistem berupa komponen untuk game networking.

5.

Protokol yang digunakan untuk melakukan komunikasi data dalam game adalah UDP (User Datagram Protocol).

6.

Model komunikasi data dalam game diimplementasikan dengan 2 buah cara yaitu, multicast transmission untuk proses discovery server-server permainan yang aktif dan server message exploding untuk sinkronisasi data antar pemain.

5.3

Implementasi Klas pada File Program Setiap klas yang telah dirancang pada proses perancangan direalisasikan

pada sebuah file program *.java. Tabel 5.3 menjelaskan mengenai pasangan antara klas dengan file program yang digunakan untuk mengimplentasikannya. Tabel 5.3 Implementasi klas pada kode program *.java No. 1.

Paket net.java.dev.boombat .multiplayer

Nama Klas

Nama File Program

Manager

Manager.java

69

2.

Announcer

Announcer.java

3.

Client

Client.java

4.

ClientHandler

ClientHandler.java

5.

Finder

Finder.java

6.

GameSession

GameSession.java

Handler

Handler.java

7.

net.java.dev.boombat .multiplayer.core

8.

Host

Host.java

9.

HostHandler

HostHandler.java

10.

SecurityFilter

SecurityFilter.java

11.

Util

Util.java

12.

AddNewPlayerMsg

AddNewPlayerMsg.java

13.

ChangePlayerNameMsg

ChangePlayerNameMsg.java

14.

ChangeTeamMsg

ChangeTeamMsg.java

15.

ChatMsg

ChatMsg.java

16.

FireBulletMsg

FireBulletMsg.java

17.

FireRocketMsg

FireRocketMsg.java

18.

InvalidLoginMsg

InvalidLoginMsg.java

19.

KeepAliveMsg

KeepAliveMsg.java

LeaveGameReqMsg

LeaveGameReqMsg.java

21.

LoginReqMsg

LoginReqMsg.java

22.

Message

Message.java

23.

RemovePlayerMsg

RemovePlayerMsg.java

24.

SessionFlagMsg

SessionFlagMsg.java

25.

SwitchMapMsg

SwitchMapMsg.java

26.

TankPositionMsg

TankPositionMsg.java

27.

ValidLoginMsg

ValidLoginMsg.java

20.

net.java.dev.boombat .multiplayer.message

Sumber: Implementasi

5.4

Implementasi Algoritma Subsistem Game Server ini mempunyai beberapa proses utama yaitu

proses bergabung dengan sesi permainan, membuat sesi permainan, mengirimkan posisi tank, menerima update posisi tank, mengirimkan fire state, menerima fire state, validasi login, mengirimkan notifikasi status permainan, menerima notifikasi status permainan, mengakhiri sesi permainan dan meninggalkan sesi permainan. 5.4.1

Implementasi Algoritma Bergabung Dengan Sesi Permainan Proses bergabung dengan sesi permainan dilakukan dengan melakukan

koneksi ke sebuah game server. Kemudian dilakukan pengiriman pesan permintaan login ke sebuah game server. Gambar 5.1 merupakan Implementasi Algoritma Bergabung Dengan Sesi Permainan.

70

METHOD joinGame PARAMETER address, name, pass, team, tank IS boolean wait IS boolean

// atribut klas

DECLARATION: TYPE address IS String name IS String pass IS int team IS byte tank IS String waitTimeOut IS int startTime IS long ok IS boolean msg IS LoginReqMsg DESCRIPTION: waitTimeOut <- 2000 1 startTime <- CALL System.currentTimeMillis() 2 ok <- CALL Client.connect(address) 3 CALL PlayerList.clear() 4 IF ok THEN 5 wait <- true 6 msg <- CREATE OBJECT LoginReqMsg() 7 msg.name <- name 8 msg.password <- pass 9 msg.tank <- tank 10 msg.team <- team 11 CALL Client.send(CALL msg.toBuffer()) 12 WHILE CALL System.currentTimeMillis() – startTime 13 waitTimeOut 14 IF !wait THEN 15 IF CALL Client.isValidConnected() THEN 16 CALL Manager.setClient(true) 17 CALL Config.setSelectedGameMap(CALL 18 Config.getMapKeyName()) 19 RETURN true 20 ELSE 21 RETURN false 22 ENDIF 23 ENDIF 24 ENDWHILE 25 ENDIF 26 RETURN false 27 END joinGame

<

Gambar 5.1 Implementasi Algoritma Bergabung Dengan Sesi Permainan Sumber: Implementasi

Penjelasan algoritma Bergabung Dengan Sesi Permainan untuk joinGame() pada Gambar 5.1 yaitu: 1. Baris 1 menjelaskan penentuan batas waktu maksimum untuk menunggu pesan jawaban login dari game server. Batas waktu yang diberikan adalah 2 detik atau 2000 milidetik. 2. Baris 2 menjelaskan pengambilan nilai waktu sekarang atau mula-mula. 3. Baris 3 menjelaskan koneksi ke dari game client ke game server. 4. Baris 4 menjelaskan penghapusan seluruh data pemain.

71

5. Baris 5-12 menjelaskan pengiriman pesan permintaan login dari game client ke game server ketika koneksi ke game server berhasil dilakukan. 6. Baris 13-25 menjelaskan game client menunggu jawaban login dari game server. Jika jawaban login dari game server valid maka akan dikembalikan nilai true, sebaliknya akan dikembalikan nilai false. 7. Baris 26 menjelaskan pengembalian nilai false ketika koneksi ke game server gagal dilakukan. 5.4.2

Implementasi Algoritma Membuat Sesi Permainan Proses pembuatan sesi permainan dilakukan dengan mengaktifkan game

server dan membuat sebuah sesi permainan. Gambar 5.2 merupakan Implementasi Algoritma Membuat Sesi Permainan. METHOD createGame PARAMETER name, pass, maxp, map, team, tank IS boolean DECLARATION: TYPE name IS String pass IS String maxp IS int map IS String team IS byte tank IS String ok IS boolean p IS Player DESCRIPTION: CALL PlayerList.clear() 1 CALL Util.resetPlayerIdCounter() 2 CALL Config.setPassword(pass) 3 CALL Config.setMaxPlayer(maxp) 4 ok <- CALL Host.start() 5 IF ok THEN 6 CALL Manager.setClient(false) 7 CALL Config.setPlayerRadar(CALL 8 Config.getOption().getBoolean(“playerRadar”)) 9 p <- CREATE OBJECT Player(CALL Util.getPlayerId(), name, CALL 10 ResourceManager.createTank(tank)) 11 CALL p.setTeam(team) 12 CALL PlayerList.addPlayer(p) 13 CALL Config.setSelectedGameMap(map) 14 CALL GameSession.startCreatorSession() 15 CALL Util.applyRandomTankPosition() 16 CALL GameSession.newRound() 17 18 CALL SystemMessageList.add(name + “ join ” + CALL 19 p.getTeamName()) 20 RETURN true 21 ELSE 22 RETURN false 23 ENDIF END createGame

Gambar 5.2 Implementasi Algoritma Membuat Sesi Permainan Sumber: Implementasi

72

Penjelasan algoritma Membuat Sesi Permainan untuk createGame() pada Gambar 5.2 yaitu: 1. Baris 1-2 menjelaskan penghapusan data pemain dan me-reset penghitung ID pemain. 2. Baris 3-4 menjelaskan konfigurasi sesi permainan yaitu, password dan jumlah maksimum yang pemain diperbolehkan dalam sesi permainan. 3. Baris 5 menjelaskan pengaktifan game server. 4. Baris 6-20 menjelaskan inisialisasi data yang dibutuhkan untuk memulai sebuah sesi permainan ketika game server aktif. Dan kemudian dikembalikan nilai true. 5. Baris 21-22 menjelaskan pengembalian nilai false ketika game server gagal diaktifkan. 5.4.3

Implementasi Algoritma Mengirimkan Posisi Tank Proses pengiriman posisi tank dilakukan dengan mengirimkan data

posisi tank yang meliputi koordinat x, y, sudut badan tank, dan sudut meriam tank ke semua pemain. Gambar 5.3 merupakan Implementasi Algoritma Mengirimkan Posisi Tank. METHOD sendTankPosition PARAMETER p IS boolean DECLARATION: TYPE p IS Player msg IS TankPositionMsg DESCRIPTION: msg <- CREATE OBJECT TankPositionMsg() 1 msg.playerId <- CALL p.getId() 2 msg.x <- CALL p.getTank().getX() 3 msg.y <- CALL p.getTank().getY() 4 msg.bodyAng <- CALL p.getTank().getBodyAngle() 5 msg.turretAng <- CALL p.getTank().getTurretAngle() 6 IF CALL isClient() THEN 7 CALL Client.send(CALL msg.toBuffer()) 8 RETURN true 9 ELSE 10 CALL Host.broadcast(CALL msg.toBuffer()) 11 RETURN false 12 ENDIF 13 END sendTankPosition 14

Gambar 5.3 Implementasi Algoritma Mengirimkan Posisi Tank Sumber: Implementasi

Penjelasan algoritma Mengirimkan Posisi Tank untuk sendTankPosition() pada Gambar 5.3 yaitu:

73

1. Baris 1 menjelaskan penciptaan objek TankPositionMsg. 2. Baris 2-6 menjelaskan pengisian data pesan posisi tank. 3. Baris 7-13 menjelaskan pengiriman data posisi tank pemain ke semua pemain lain dengan mengubah data pesan menjadi IoBuffer terlebih dahulu. 5.4.4

Implementasi Algoritma Menerima Update Posisi Tank Proses update posisi tank dilakukan dengan memperbarui data posisi

tank sesuai ID pemain. Gambar 5.4 merupakan Implementasi Algoritma Menerima Update Posisi Tank. METHOD updateTankPosition PARAMETER message IS boolean DECLARATION: TYPE message IS Message msg IS TankPositionMsg p IS Player DESCRIPTION: msg <- (TankPositionMsg) message 1 p <- CALL PlayerList.getPlayer(msg.playerId) 2 IF p != NULL THEN 3 CALL p.getTank().setX(msg.x) 4 CALL p.getTank().setY(msg.y) 5 CALL p.getTank().setBodyAngle(msg.bodyAng) 6 CALL p.getTank().setTurretAngle(msg.turretAng) 7 RETURN true 8 ENDIF 9 RETURN false 10 END updateTankPosition 11

Gambar 5.4 Implementasi Algoritma Menerima Update Posisi Tank Sumber: Implementasi

Penjelasan

algoritma

Menerima

Update

Posisi

Tank

untuk

updateTankPosition() pada Gambar 5.4 yaitu:

1. Baris 2 menjelaskan pencarian data pemain berdasarkan ID pemain. 2. Baris 3-9 menjelaskan update posisi tank pemain yang meliputi koordinat x, y, sudut badan tank, dan sudut meriam tank dan pengembalian nilai return true ketika data pemain yang dicari ada. 3. Baris 10 menjelaskan pengembalian nilai return false. 5.4.5

Implementasi Algoritma Mengirimkan Fire State Proses pengiriman pesan notifikasi ketika pemain melakukan tembakan

rudal atau senjata mesin dilakukan dengan mengirimkan pesan notifikasi

74

tembakan pemain sesuai tipe tembakan ke semua pemain. Gambar 5.5 merupakan Implementasi Algoritma Mengirimkan Fire State. METHOD sendFireState PARAMETER playerId, msgId IS int DECLARATION: TYPE playerId IS byte msgId IS byte fireBulletMsg IS FireBulletMsg fireRocketMsg IS FireRocketMsg DESCRIPTION: IF FireBulletMsg.ID == msgId THEN 1 2 fireBulletMsg = CREATE OBJECT FireBulletMsg() 3 fireBulletMsg.playerId <- playerId 4 IF CALL isClient() THEN 5 CALL Client.send(CALL fireBulletMsg.toBuffer()) 6 RETURN 1 7 ELSE 8 CALL Host.broadcast(CALL fireBulletMsg.toBuffer()) 9 RETURN 2 10 ENDIF 11 ELSE IF FireRocketMsg.ID == msgId THEN 12 fireRocketMsg = CREATE OBJECT FireRocketMsg() 13 fireRocketMsg.playerId <- playerId 14 IF CALL isClient() THEN 15 CALL Client.send(CALL fireRocketMsg.toBuffer()) 16 RETURN 3 17 ELSE 18 CALL Host.broadcast(CALL fireRocketMsg.toBuffer()) 19 RETURN 4 20 ENDIF 21 ENDIF 22 RETURN 0 23 END sendFireState

Gambar 5.5 Implementasi Algoritma Mengirimkan Fire State Sumber: Implementasi

Penjelasan algoritma Mengirimkan Fire State untuk sendFireState() pada Gambar 5.5 yaitu: 1. Baris 1-10 menjelaskan pengiriman pesan notifikasi bahwa pemain menembakkan senjata mesin ke pemain lain dengan mengubah data pesan menjadi IoBuffer terlebih dahulu. 2. Baris 9-21 menjelaskan pengiriman pesan notifikasi bahwa pemain menembakkan rudal ke pemain lain dengan mengubah data pesan menjadi IoBuffer terlebih dahulu. 3. Baris 22 menjelaskan pengembalian nilai return 0 jika nilai msgId selain FireBulletMsg.ID dan FireRocketMsg.ID.

75

5.4.6

Implementasi Algoritma Menerima Fire State Proses penerimaan notifikasi ketika pemain lain melakukan tembakan

dengan senjata mesin atau rudal dilakukan dengan memeriksa tipe tembakan terlebih dahulu. Gambar 5.6 merupakan Implementasi Algoritma Menerima Fire State. METHOD receiveFireState PARAMETER message, msgId IS boolean DECLARATION: TYPE message IS Message msgId IS byte fireBulletMsg IS FireBulletMsg fireRocketMsg IS FireRocketMsg p IS Player DESCRIPTION: IF FireBulletMsg.ID == msgId THEN 1 fireBulletMsg <- (FireBulletMsg) message 2 p <- CALL PlayerList.getPlayer(fireBulletMsg.playerId) 3 IF p != NULL THEN 4 CALL p.getTank().fireBullet() 5 RETURN true 6 ENDIF 7 RETURN false 8 ELSE IF FireRocketMsg.ID == msgId THEN 9 fireRocketMsg <- (FireRocketMsg) message 10 p <- CALL PlayerList.getPlayer(CALL fireRocketMsg.playerId) 11 IF p != NULL THEN 12 CALL p.getTank().fireRocket() 13 RETURN true 14 ENDIF 15 RETURN false 16 ENDIF 17 RETURN false 18 END receiveFireState 19

Gambar 5.6 Implementasi Algoritma Menerima Fire State Sumber: Implementasi

Penjelasan algoritma Menerima Fire State untuk receiveFireState() pada Gambar 5.6 yaitu: 1. Baris 1-8 menjelaskan pemeriksaan kondisi tipe tembakan pemain apakah tipe tembakan merupakan tembakan senjata mesin. Jika memenuhi kondisi tersebut maka akan dilakukan pencarian data pemain sesuai dengan ID pemain yang melakukan tembakan. Dan kemudian jika data pemain ditemukan akan dipanggil method fireBullet() dan dikembalikan nilai return true.Jika data pemain tidak ditemukan akan dilakukan pengembalian nilai return false. 2. Baris 9-17 menjelaskan pemeriksaan kondisi tipe tembakan pemain apakah tipe tembakan merupakan tembakan rudal. Jika memenuhi

76

kondisi tersebut maka akan dilakukan pencarian data pemain sesuai dengan ID pemain yang melakukan tembakan. Dan kemudian jika data pemain ditemukan akan dipanggil method fireRocket() dan dikembalikan nilai return true. Jika data pemain tidak ditemukan akan dilakukan pengembalian nilai return false. 3. Baris 18 akan menjelaskan pengembalikan nilai return false jika nilai msgId selain FireBulletMsg.ID dan FireRocketMsg.ID 5.4.7

Implementasi Algoritma Mengirimkan Notifikasi Status Permainan Proses pengiriman notifikasi status permainan dilakukan dengan

mengirimkan pesan notifikasi status permainan yang meliputi mengulangi ronde permainan, memulai ronde permainan yang baru, dan mengakhiri sesi permainan oleh creator ke semua joiner. Gambar 5.7 merupakan Implementasi Algoritma Mengirimkan Notifikasi Status Permainan. METHOD sendGameState PARAMETER flags IS int DECLARATION: TYPE flags IS byte pos IS Map msg IS SessionFlagMsg futures IS Set f IS WriteFuture DESCRIPTION: IF SessionFlagMsg.NEW_ROUND == flags THEN 1 pos <- CALL Util.applyRandomTankPosition() 2 msg <- CREATE OBJECT SessionFlagMsg() 3 msg.flags <- SessionFlagMsg.NEW_ROUND 4 msg.pos <- pos 5 CALL Host.broadcast(CALL msg.toBuffer()) 6 RETURN 2 7 ELSE IF SessionFlagMsg.RESTART_ROUND == flags THEN 8 pos <- CALL Util.applyRandomTankPosition() 9 msg <- CREATE OBJECT SessionFlagMsg() 10 msg.flags <- SessionFlagMsg.RESTART_ROUND 11 CALL Host.broadcast(CALL msg.toBuffer()) 12 RETURN 1 13 ELSE IF SessionFlagMsg.END_SESSION == flags THEN 14 msg <- CREATE OBJECT SessionFlagMsg() 15 msg.flags <- SessionFlagMsg.END_SESSION 16 futures <- CALL Host.broadcast(CALL msg.toBuffer()) 17 FOR f:futures DO 18 CALL f.awaitUninterruptibly(1000) 19 ENDFOR 20 CALL Host.destroy() 21 RETURN 3 22 ENDIF 23 RETURN 0 24 END sendGameState 25 Gambar 5.7 Implementasi Algoritma Mengirimkan Notifikasi Status Permainan

Sumber: Implementasi

77

Penjelasan

algoritma

mengirimkan

notifikasi

status

permainan

untuk

sendGameState() pada Gambar 5.7 yaitu:

1. Baris 1-7 menjelaskan pengiriman pesan notifikasi status permainan ke semua joiner dan pengembalian nilai return 2 ketika creator memulai ronde permainan yang baru. 2. Baris 8-13 menjelaskan pengiriman pesan notifikasi status permainan ke semua joiner dan pengembalian nilai return

1 ketika creator

mengulangi ronde permainan yang sedang berlangsung. 3. Baris 14-23 menjelaskan pengiriman pesan notifikasi status permainan dan pengembalian nilai return 3 ketika creator mengakhiri sesi permainan yang sedang berlangsung. Dan kemudian game server dimatikan. 4. Baris 24 menjelaskan pengembalian nilai return 0 jika nilai flags selain

SessionFlagMsg.NEW_ROUND,

SessionFlagMsg.RESTART_ROUND,

dan

SessionFlagMsg.END_SESSION.

5.4.8

Implementasi Algoritma Menerima Notifikasi Status Permainan Proses penerimaan notifikasi status permainan dilakukan dengan

memeriksa tipe pesan notifikasi status permainan terlebih dahulu. Gambar 5.8 merupakan Implementasi Algoritma Menerima Notifikasi Status Permainan. METHOD updateGameState PARAMETER message IS int DECLARATION: TYPE message IS Message msg IS SessionFlagMsg DESCRIPTION: msg <- (SessionFlagMsg) message 1 IF SessionFlagMsg.NEW_ROUND == msg.flags THEN 2 CALL GameSession.calculateScore() 3 CALL GameSession.roundNotify() 4 CALL GameSession.newRound() 5 CALL Util.updateAllTankPosition(msg.pos) 6 RETURN 2 7 ELSE IF SessionFlagMsg.RESTART_ROUND == msg.flags THEN 8 CALL FlashMessageBox.instance().showFlashMessage(2000, “Round 9 Restarted”) 10 CALL GameSession.restartRound() 11 CALL Util.updateAllTankPosition(msg.pos) 12 RETURN 1 13 ELSE IF SessionFlagMsg.END_SESSION == msg.flags THEN 14 CALL GameSession.endSession() 15

78

16 17 18 19

RETURN 3 ENDIF RETURN 0 END updateGameState

Gambar 5.8 Implementasi Algoritma Menerima Notifikasi Status Permainan Sumber: Implementasi

Penjelasan

algoritma

menerima

notifikasi

status

permainan

untuk

updateGameState() pada Gambar 5.8 yaitu:

1. Baris 2-7 menjelaskan pemeriksaan tipe pesan notifikasi status permainan yang masuk. Jika pesan notifikasi status permainan tersebut menginformasikan bahwa creator memerintahkan untuk memulai ronde permainan yang baru maka akan dilakukan penghitungan score dan ronde permainan yang baru akan dimulai dan pengembalian nilai return 2.

2. Baris 8-13 menjelaskan pemeriksaan tipe pesan notifikasi status permainan yang masuk. Jika pesan notifikasi status permainan tersebut menginformasikan bahwa creator memerintahkan untuk mengulangi ronde permainan yang sedang berlangsung maka dilakukan pengulangan ronde permainan dan pengembalian nilai return 1. 3. Baris 14-17 menjelaskan pemeriksaan tipe pesan notifikasi status permainan yang masuk. Jika pesan notifikasi status permainan tersebut menginformasikan bahwa creator memerintahkan untuk mengakhiri sesi permainan maka sesi permainan yang sedang berlangsung diakhiri dan pengembalian nilai return 3. 4. Baris 18 menjelaskan pengembalian nilai return 0 jika jika nilai flags SessionFlagMsg.NEW_ROUND,

selain SessionFlagMsg.RESTART_ROUND,

dan

SessionFlagMsg.END_SESSION.

5.4.9

Implementasi Algoritma Mengakhiri Sesi Permainan Gambar 5.9 merupakan Implementasi Algoritma Mengakhiri Status

Permainan.

79

METHOD endGame DECLARATION: DESCRIPTION: CALL GameSession.endSession() 1 CALL Manager.sendGameState(SessionFlagMsg.END_SESSION) 2 END endGame 3

Gambar 5.9 Implementasi Algoritma Mengakhiri Sesi Permainan Sumber: Implementasi

Penjelasan algoritma mengakhiri sesi permainan untuk endGame() pada Gambar 5.10 yaitu: 1. Baris 1 menjelaskan creator mengakhiri sebuah sesi permainan. 2. Baris 2 menjelaskan pengiriman notifikasi status permainan ke semua joiner bahwa sesi permainan akan diakhiri dan game server dimatikan. 5.4.10

Implementasi Algoritma Meninggalkan Sesi Permainan Gambar 5.10 merupakan Implementasi Algoritma Meninggalkan Sesi

Permainan. METHOD leaveGame DECLARATION: TYPE playerId IS byte msg IS LeaveGameReqMsg DESCRIPTION: playerId <- CALL PlayerList.getLocalPlayer().getId() 1 msg <- CREATE OBJECT LeaveGameReqMsg() 2 msg.playerId <- playerId 3 CALL Client.send(CALL msg.toBuffer()).awaitUniterruptibly(1000) 4 CALL GameSession.endSession() 5 CALL Client.destroy() 6 END leaveGame 7

Gambar 5.11 Implementasi Algoritma Meninggalkan Sesi Permainan Sumber: Implementasi

Penjelasan algoritma meninggalkan sesi permainan untuk leaveGame() pada Gambar 5.10 yaitu: 1. Baris 1 menjelaskan pengambilan ID pemain lokal. 2. Baris 2-3 menjelaskan pembuatan objek pesan permintaan keluar dari sesi permainan. 3. Baris 4-6 menjelaskan pengiriman pesan permintaan keluar dari sesi permainan ke creator atau game server. Dan kemudian joiner keluar dari sesi permainan.

80

5.5

Kendala dalam Implementasi Proses implementasi mempunyai kendala yaitu terbatasnya alokasi

memori untuk JVM (Java Virtual Machine). Untuk melakukan komunikasi data secara realtime dalam multiplayer tank game dengan jumlah pemain yang banyak dibutuhkan alokasi memori yang banyak. Maka memungkinkan terjadinya memory leaks. Hal ini dapat diatasi dengan cara menambah alokasi memori JVM menggunakan opsi –xms128m dan –xmx512m, dimana –xms digunakan untuk batasan minimal alokasi JVM, sedangkan –xmx adalah alokasi maksimum JVM. Ukuran ini bisa diubah sesuai dengan keinginan dengan mempertimbangkan memori RAM komputer.

81

BAB VI PENGUJIAN DAN ANALISIS Pada bab ini dilakukan proses pengujian dan analisis terhadap subsistem Game Server yang telah dibangun. Proses pengujian dilakukan melalui tiga tahapan (strategi) yaitu pengujian unit, pengujian integrasi dan pengujian validasi. Pada pengujian unit dan pengujian integrasi, akan digunakan teknik pengujian White Box (White Box Testing). Pada pengujian validasi akan digunakan teknik pengujian Black Box (Black Box Testing).

Proses analisis dilakukan untuk

mengetahui performa dari subsistem Game Server. Sedangkan pengujian dan analisis subsistem Game Client dibahas dalam skripsi yang berjudul “Pengembangan 2D Game Client Untuk Multiplayer Tank Game Menggunakan Teknologi Java” oleh Murti Daryandono (Teknik Elektro Universitas Brawijaya, 2008). 6.1

Pengujian Proses pengujian dilakukan melalui tiga tahapan (strategi) yaitu

pengujian unit, pengujian integrasi dan pengujian validasi. 6.1.1

Pengujian Unit Sistem yang dibangun dengan paradigma pemrograman berorientasi

objek menerapkan pengujian unit untuk suatu metode (operasi) dari suatu klas. Pada pengujian unit subsistem Game Server ini, digunakan teknik pengujian White Box (White Box Testing) dengan teknik Basis Path Testing. Pada teknik Basis Path Testing, proses pengujian dilakukan dengan memodelkan algoritma pada suatu flow graph, menentukan jumlah kompleksitas siklomatis (cyclomatic complexity), menentukan sebuah basis set dari jalur independen dan memberikan kasus uji (test case) pada setiap basis set yang telah ditentukan. Penulisan laporan skripsi ini hanya dicantumkan hasil pengujian unit untuk algoritma dari beberapa metode (operasi) saja (tidak untuk keseluruhan metode) pada subsistem game server.

82

a.

Pengujian Unit untuk Operasi broadcast() Operasi broadcast() merupakan implementasi algoritma untuk

mengirimkan data dari game server atau creator ke beberapa game client atau joiner. Operasi broadcast() ini terdapat dalam klas Host. Gambar 6.1 menunjukkan proses pemodelan dalam flow graph pada operasi broadcast() pada klas Host. METHOD broadcast PARAMETER msg IS Set acceptor IS NioDatagramAcceptor // atribut klas

Node (N) = 1 Edge (E) = 0

DECLARATION: TYPE msg IS IoBuffer DESCRIPTION: RETURN CALL acceptor.broadcast(msg) END broadcast

Gambar 6.1

1

Pemodelan algoritma broadcast() ke dalam flow graph Sumber: Pengujian

Pemodelan ke dalam flow graph yang telah dilakukan terhadap operasi broadcast()menghasilkan

jumlah

kompleksitas

siklomatis

(cyclomatic

complexity) melalui persamaan V(G) = E – N + 2, dimana V(G) merupakan jumlah kompleksitas siklomatis, E merupakan sisi (garis penghubung antar node) dan N merupakan jumlah simpul (node). V(G) = E – N + 2 =0–1+2 =1 Dari nilai cyclomatic complexity yang telah dihasilkan dari perhitungan yaitu ditentukan satu buah basis set dari jalur independent yaitu: Jalur 1 : 1 Proses pengujian untuk operasi broadcast() yang ada di klas Host menggunakan sebuah klas dummy yaitu klas BroadcastTest. Atribut dan operasi yang ada dalam klas BroadcastTest seperti ditunjukkan dalam Gambar 6.2.

Gambar 6.2

Diagram klas dummy BroadcastTest Sumber: Pengujian

83

Penentuan kasus uji untuk masing-masing jalur dan hasil eksekusi untuk masingmasing kasus uji dijelaskan pada Tabel 6.1. Tabel 6.1 Test case untuk pengujian unit operasi broadcast() Jalur 1

Kasus uji Broadcast data ke client berupa IoBuffer.

Hasil yang diharapkan Method mengembalikan objek bertipe Set

Hasil yang didapatkan Method mengembalikan objek bertipe Set

Sumber: Pengujian

b.

Pengujian Unit untuk Operasi reply() Operasi

reply()

merupakan

implementasi

algoritma

untuk

mengirimkan pesan jawaban dari game server atau creator ke game client atau joiner. Operasi (metode) reply() terdapat di dalam klas Host. Gambar 6.2 menunjukkan proses pemodelan dalam flow graph pada operasi reply(). METHOD reply PARAMETER msg, sender IS WriteFuture

Node (N) = 1 Edge (E) = 0

DECLARATION: TYPE msg IS IoBuffer sender IS IoSession DESCRIPTION: RETURN CALL sender.write(msg) END reply

Gambar 6.3

1

Pemodelan algoritma reply() ke dalam flow graph Sumber: Pengujian

Pemodelan ke dalam flow graph yang telah dilakukan terhadap operasi reply()menghasilkan jumlah kompleksitas siklomatis (cyclomatic complexity)

melalui persamaan V(G) = E – N + 2. V(G) = E – N + 2 =0–1+2 =1 Dari nilai cyclomatic complexity yang telah dihasilkan dari perhitungan yaitu ditentukan satu buah basis set dari jalur independent yaitu: Jalur 1 : 1 Proses pengujian untuk operasi reply() ada di klas Host menggunakan sebuah klas dummy yaitu klas ReplyTest. Atribut dan operasi yang ada dalam klas ReplyTest seperti ditunjukkan dalam Gambar 6.4.

84

Gambar 6.4

Diagram klas dummy ReplyTest Sumber: Pengujian

Penentuan kasus uji untuk masing-masing jalur dan hasil eksekusi untuk masingmasing kasus uji dijelaskan pada Tabel 6.2. Tabel 6.2 Test case untuk pengujian unit operasi reply() Jalur 1

Kasus uji Reply data ke client berupa IoBuffer

Hasil yang diharapkan Method mengembalikan objek bertipe WriteFuture

Hasil yang didapatkan Method mengembalikan objek bertipe WriteFuture

Sumber: Pengujian

c.

Pengujian Unit untuk Operasi send() Operasi send() merupakan implementasi algoritma untuk mengirimkan

data dari game client atau joiner ke game server atau creator. Operasi (metode) send() terdapat di dalam klas Client.

Gambar 6.5 menunjukkan proses

pemodelan dalam flow graph pada operasi send(). METHOD send PARAMETER msg IS WriteFuture session IS IoSession // atribut klas

Node (N) = 1 Edge (E) = 0

DECLARATION: TYPE msg IS IoBuffer DESCRIPTION: RETURN CALL session.write(msg) END send

Gambar 6.5

1

Pemodelan algoritma send() ke dalam flow graph Sumber: Pengujian

Pemodelan ke dalam flow graph yang telah dilakukan terhadap operasi send() menghasilkan jumlah kompleksitas siklomatis (cyclomatic complexity)

melalui persamaan V(G) = E – N + 2. V(G) = E – N + 2 =0–1+2 =1 Dari nilai cyclomatic complexity yang telah dihasilkan dari perhitungan yaitu ditentukan satu buah basis set dari jalur independent yaitu: Jalur 1 : 1

85

Proses pengujian untuk operasi send() yang ada di klas Client menggunakan sebuah klas dummy yaitu klas SendTest. Atribut dan operasi yang ada dalam klas SendTest seperti ditunjukkan dalam Gambar 6.6.

Gambar 6.6

Diagram klas dummy SendTest Sumber: Pengujian

Penentuan kasus uji untuk masing-masing jalur dan hasil eksekusi untuk masingmasing kasus uji dijelaskan pada Tabel 6.3. Tabel 6.3 Test case untuk pengujian unit operasi send() Jalur 1

Kasus uji Mengirim data ke server berupa IoBuffer

Hasil yang diharapkan Method mengembalikan objek bertipe WriteFuture

Hasil yang didapatkan Method mengembalikan objek bertipe WriteFuture

Sumber: Pengujian

d.

Pengujian Unit untuk Operasi start() Operasi

start()

merupakan

implementasi

algoritma

untuk

mengaktifkan sebuah game server. Operasi (metode) start() terdapat di dalam klas Host. Gambar 6.7 menunjukkan proses pemodelan dalam flow graph pada operasi start(). METHOD start IS boolean

Node (N) = 3 Edge (E) = 3

acceptor IS NioDatagramAcceptor announcer IS Announcer PORT IS int

// atribut klas // atribut klas // atribut klas

DECLARATION: DESCRIPTION: 1 TRY CALL IoBuffer.setUseDirectBuffer(Message.USE_DIRECT_BUFFER) CALL IoBuffer.setAllocator(CREATE OBJECT SimpleBufferAllocator()) acceptor <- CREATE OBJECT NioDatagramAcceptor(); CALL acceptor.setHandler(CREATE OBJECT HostHandler()) CALL acceptor.getSessionConfig().setReuseAddress(false) CALL acceptor.getSessionConfig().setBroadcast(false) 2 CALL acceptor.getFilterChain().addLast("security", CREATE OBJECT SecurityFilter()) CALL acceptor.bind(CREATE OBJECT InetSocketAddress(PORT)) announcer <- CREATE OBJECT Announcer() CALL Executors.newCachedThreadPool().execute(announcer) RETURN true CATCH (IOException e) 3 RETURN false ENDTRY 4 END start

Gambar 6.7

Pemodelan algoritma start() ke dalam flow graph Sumber: Pengujian

86

Pemodelan ke dalam flow graph yang telah dilakukan terhadap operasi start() menghasilkan jumlah kompleksitas siklomatis (cyclomatic complexity)

melalui persamaan V(G) = E – N + 2. V(G) = E – N + 2 =3-3+2 =2 Dari nilai cyclomatic complexity yang telah dihasilkan dari perhitungan yaitu ditentukan dua buah basis set dari jalur independent yaitu: Jalur 1 : 1 – 2 – 4 Jalur 2 : 1 – 3 – 4 Proses pengujian untuk operasi start() yang ada di klas Host menggunakan sebuah klas dummy yaitu klas ServerStartupTest. Atribut dan operasi yang ada dalam klas ServerStartupTest seperti ditunjukkan dalam Gambar 6.8.

Gambar 6.8

Diagram klas dummy ServerStartupTest Sumber: Pengujian

Penentuan kasus uji untuk masing-masing jalur dan hasil eksekusi untuk masingmasing kasus uji dijelaskan pada Tabel 6.4. Tabel 6.4 Test case untuk pengujian unit operasi start() Jalur 1

2

Kasus uji Tidak ada aplikasi yang melakukan bind pada port 3003 pada mesin yang sama Ada aplikasi yang melakukan bind pada port 3003 pada mesin yang sama

Hasil yang diharapkan Server berhasil diaktifkan. Method mengembalikan nilai return : true

Server gagal diaktifkan. Method mengembalikan nilai return : false

Hasil yang didapatkan Server berhasil diaktifkan. Method mengembalikan nilai return : true Server gagal diaktifkan. Method mengembalikan nilai return : false

Sumber: Pengujian

e.

Pengujian Unit untuk Operasi connect() Operasi

connect()

melakukan koneksi

merupakan

implementasi

algoritma

untuk

ke sebuah game server. Operasi (metode) connect()

terdapat di dalam klas Client. Gambar 6.9 menunjukkan proses pemodelan dalam flow graph pada operasi connect().

87

METHOD connect PARAMETER address IS boolean connector IS NioDatagramConnector session IS IoSession TIMEOUT IS int

Node (N) = 7 Edge (E) = 8 // atribut klas // atribut klas // atribut klas

DECLARATION: TYPE addr IS InetSocketAddress conn IS ConnectFuture

2

4

5 7

DESCRIPTION: addr <- CREATE OBJECT InetSocketAddress(address, Host.PORT) 1 IF CALL addr.isUnresolved() THEN RETURN false 3 ENDIF CALL IoBuffer.setUseDirectBuffer(Message.USE_DIRECT_BUFFER) CALL IoBuffer.setAllocator(CREATE OBJECT SimpleBufferAlocator()) connector <- CREATE OBJECT NioDatagramConnector() CALL connector.setHandler(CREATE OBJECT ClientHandler()) CALL connector.getSessionConfig().setReuseAddress(true) CALL connector.getSessionConfig().setBroadcast(false) CALL connector.setDefaultRemoteAddress(addr) conn <- CALL connector.connect() conn.awaitUninterruptibly(TIMEOUT) session <- CALL conn.getSession() IF session == null THEN RETURN false 6 ENDIF RETURN true END connect

Gambar 6.9

Pemodelan algoritma connect() ke dalam flow graph Sumber: Pengujian

Pemodelan ke dalam flow graph yang telah dilakukan terhadap operasi connect()

menghasilkan

jumlah

kompleksitas

siklomatis

(cyclomatic

complexity) melalui persamaan V(G) = E – N + 2. V(G) = E – N + 2 =7–8+2 =3 Dari nilai cyclomatic complexity yang telah dihasilkan dari perhitungan yaitu ditentukan tiga buah basis set dari jalur independent yaitu: Jalur 1 : 1 – 2 – 3 – 4 – 5 – 6 – 7 Jalur 2 : 1 – 2 – 4 – 5 – 6 – 7 Jalur 3 : 1 – 2 – 4 – 5 – 7 Proses pengujian untuk operasi connect() yang ada di klas Host menggunakan sebuah klas dummy yaitu klas ClientConnectorTest. Atribut dan operasi yang ada dalam klas ClientConnectorTest seperti ditunjukkan dalam Gambar 6.10.

88

Gambar 6.10 Diagram klas dummy ClientConnectorTest Sumber: Pengujian

Penentuan kasus uji untuk masing-masing jalur dan hasil eksekusi untuk masingmasing kasus uji dijelaskan pada Tabel 6.5. Tabel 6.5 Jalur 1

2

3

Test case untuk pengujian unit operasi connect()

Kasus uji Koneksi ke server aktif yang mempunyai ip address “localhost” pada port 3003 Koneksi ke server dengan unresolved ip address “unknown” pada port 3003 Koneksi ke server yang tidak aktif dengan ip address “10.100.100.10” pada port 3003

Hasil yang diharapkan Koneksi ke server berhasil dilakukan. Method mengembalikan nilai return : true Koneksi ke server gagal dilakukan. Method mengembalikan nilai return : false Koneksi ke server gagal dilakukan. Method mengembalikan nilai return : false

Hasil yang didapatkan Koneksi ke server berhasil dilakukan. Method mengembalikan nilai return : true Koneksi ke server gagal dilakukan. Method mengembalikan nilai return : false Koneksi ke server gagal dilakukan. Method mengembalikan nilai return : false

Sumber: Pengujian

6.1.2

Pengujian Integrasi Pengujian integrasi diterapkan pada proses yang mengintegrasikan

fungsionalitas dari beberapa klas untuk melakukan sebuah operasi tertentu. Pada pengujian integrasi yang dijadikan sebagai obyek uji adalah klas-klas yang menggabungkan kinerja dari klas-klas yang lain. Pengujian integrasi dilakukan terhadap subsistem game server ini menggunakan strategi bottom-up, dimana modul-modul yang diintegrasikan masing-masing diuji terlebih dahulu dalam pengujian unit (dengan menggunakan klas dummy sebagai test driver) dan kemudian

bergerak

menuju

ke

pengujian

modul-modul

kontrol

yang

mengintegrasikannya. a.

Pengujian Integrasi untuk Operasi joinGame() Operasi joinGame() merupakan implementasi dari algoritma proses

penggabungan ke sebuah sesi permainan. Operasi (metode) joinGame() terdapat di dalam klas Manager. Gambar 6.11 memperlihatkan proses pemodelan dalam flow graph pada operasi joinGame().

89

METHOD joinGame PARAMETER address, name, pass, team, tank IS boolean wait IS boolean

Node (N) = 15 Edge (E) = 12

// atribut klas

DECLARATION: TYPE address IS String name IS String pass IS int team IS byte tank IS String waitTimeOut IS int startTime IS long ok IS boolean msg IS LoginReqMsg

1 2

12

DESCRIPTION: waitTimeOut <- 2000 startTime <- CALL System.currentTimeMillis() ok <- CALL Client.connect(address) CALL PlayerList.clear() IF ok THEN wait <- true msg <- CREATE OBJECT LoginReqMsg() msg.name <- name 3 msg.password <- pass msg.tank <- tank msg.team <- team CALL Client.send(CALL msg.toBuffer()) WHILE CALL System.currentTimeMillis() – startTime 4 < waitTimeOut 5 IF !wait THEN 6 IF CALL Client.isValidConnected() THEN CALL Manager.setClient(true) CALL Config.setSelectedGameMap(CALL 7 Config.getMapKeyName()) RETURN true ELSE 8 RETURN false 9 ENDIF 10 ENDIF 11 ENDWHILE ENDIF RETURN false END joinGame

Gambar 6.11 Pemodelan algoritma joinGame() ke dalam flow graph Sumber: Pengujian

Pemodelan ke dalam flow graph yang telah dilakukan terhadap operasi joinGame()

menghasilkan

jumlah

kompleksitas

siklomatis

(cyclomatic

complexity) melalui persamaan V(G) = E – N + 2 . V(G) = E – N + 2 = 15 – 12 + 2 = 5 Dari nilai cyclomatic complexity yang telah dihasilkan dari perhitungan yaitu ditentukan lima buah basis set dari jalur independent yaitu: Jalur 1 : 1 – 2 – 12 Jalur 2 : 1 – 2 – 3 – 4 – 12

90

Jalur 3 : 1 – 2 – 3 – 4 – 5 – 10 – 11 – 4 – ... Jalur 4 : 1 – 2 – 3 – 4 – 5 – 6 – 7 – 9 – 10 – 11 – 4 – ... Jalur 5 : 1 – 2 – 3 – 4 – 5 – 6 – 8 – 9 – 10 – 11 – 4 – ... Proses pengujian untuk operasi joinGame() di klas Manager menggunakan sebuah klas dummy yaitu klas JoinGameTest. Atribut dan operasi yang ada dalam klas JoinGameTest seperti ditunjukkan dalam Gambar 6.12.

Gambar 6.12 Diagram klas dummy JoinGameTest Sumber: Pengujian

Penentuan kasus uji untuk masing-masing jalur dan hasil eksekusi untuk masingmasing kasus uji dijelaskan pada Tabel 6.6. Tabel 6.6 Test case untuk pengujian integrasi operasi joinGame() Jalur 1

2

3

4

Kasus uji Bergabung dengan sebuah sesi permainan dengan memasukkan unresolved ip address atau ip address server yang tidak aktif Lama waktu menunggu jawaban login dari server lebih dari waktu timeout (2000 ms) dan server tidak mengirimkan pesan jawaban login Server belum mengirimkan pesan jawaban login dan waktu tunggu belum timeout Bergabung dengan sesi permainan dengan memasukkan valid password dan jumlah pemain tidak melebihi jumlah maksimum

Hasil yang diharapkan Method mengembalikan nilai return : false

Hasil yang didapatkan Method mengembalikan nilai return : false

Method mengembalikan nilai return : false

Method mengembalikan nilai return : false

Sistem menunggu pesan jawaban login dari server

Sistem menunggu pesan jawaban login dari server

Method mengembalikan nilai return : true

Method mengembalikan nilai return : true

91

5

pemain sehingga server mengirimkan pesan jawaban login bahwa permintaan login diterima dan waktu tunggu belum timeout Bergabung dengan sesi permainan dengan memasukkan invalid password atau jumlah pemain melebihi jumlah maksimum pemain sehingga server mengirimkan pesan jawaban login bahwa permintaan login ditolak dan waktu tunggu belum timeout

Method mengembalikan nilai return : false

Method mengembalikan nilai return : false

Sumber: Pengujian

b.

Pengujian Integrasi untuk Operasi createGame() Operasi createGame() merupakan implementasi dari algoritma proses

pembuatan sebuah sesi permainan. Operasi (metode) createGame() terdapat di dalam klas Manager. Gambar 6.13 memperlihatkan proses pemodelan dalam flow graph pada operasi createGame(). METHOD createGame PARAMETER name, pass, maxp, map, team, tank IS boolean DECLARATION: TYPE name IS String pass IS String maxp IS int map IS String team IS byte tank IS String ok IS boolean p IS Player

1

3

DESCRIPTION: CALL PlayerList.clear() CALL Util.resetPlayerIdCounter() CALL Config.setPassword(pass) CALL Config.setMaxPlayer(maxp) ok <- CALL Host.start() IF ok THEN 2 CALL Manager.setClient(false) CALL Config.setPlayerRadar(CALL Config.getOption().getBoolean(“playerRadar”)) p <- CREATE OBJECT Player(CALL Util.getPlayerId(), name, CALL ResourceManager.createTank(tank)) CALL p.setTeam(team) CALL PlayerList.addPlayer(p) CALL Config.setSelectedGameMap(map) CALL GameSession.startCreatorSession() CALL Util.applyRandomTankPosition() CALL GameSession.newRound() CALL SystemMessageList.add(name + “ join ” + CALL p.getTeamName()) RETURN true ELSE 4 RETURN false

92

Node (N) = 5 Edge (E) = 5

ENDIF END createGame

5

Gambar 6.13 Pemodelan algoritma createGame() ke dalam flow graph Sumber: Pengujian

Pemodelan ke dalam flow graph yang telah dilakukan terhadap operasi createGame() menghasilkan jumlah kompleksitas siklomatis (cyclomatic

complexity) melalui persamaan V(G) = E – N + 2 . V(G) = E – N + 2 = 5–5+2 = 2 Dari nilai cyclomatic complexity yang telah dihasilkan dari perhitungan yaitu ditentukan dua buah basis set dari jalur independent yaitu: Jalur 1 : 1 – 2 – 3 – 5 Jalur 2 : 1 – 2 – 4 – 5 Proses pengujian untuk operasi createGame() di klas Manager menggunakan sebuah klas dummy yaitu klas CreateGameTest. Atribut dan operasi yang ada dalam klas CreateGameTest seperti ditunjukkan dalam Gambar 6.14.

Gambar 6.14 Diagram klas dummy CreateGameTest Sumber: Pengujian

Penentuan kasus uji untuk masing-masing jalur dan hasil eksekusi untuk masingmasing kasus uji dijelaskan pada Tabel 6.7. Tabel 6.7 Test case untuk pengujian integrasi operasi createGame() Jalur 1

2

Kasus uji Membuat sesi permainan dengan kondisi tidak ada aplikasi yang melakukan bind pada port 3003 pada mesin yang sama Membuat sesi permainan dengan

Hasil yang diharapkan Method mengembalikan nilai return : true

Method mengembalikan nilai return : false

93

Hasil yang didapatkan Method mengembalikan nilai return : true

Method mengembalikan nilai return : false

kondisi ada aplikasi yang melakukan bind pada port 3003 pada mesin yang sama Sumber: Pengujian

c.

Pengujian Integrasi untuk Operasi sendTankPosition() Operasi

merupakan

sendTankPosition()

implementasi

dari

algoritma proses pengiriman data posisi tank pemain. Operasi (metode) sendTankPosition() terdapat di dalam klas Manager.

Gambar 6.15

memperlihatkan

pada

proses

pemodelan

dalam

flow

graph

operasi

sendTankPosition(). METHOD sendTankPosition PARAMETER p IS boolean

Node (N) = 5 Edge (E) = 5

DECLARATION: TYPE p IS Player msg IS TankPositionMsg

1

5

DESCRIPTION: msg <- CREATE OBJECT TankPositionMsg() msg.playerId <- CALL p.getId() msg.x <- CALL p.getTank().getX() msg.y <- CALL p.getTank().getY() msg.bodyAng <- CALL p.getTank().getBodyAngle() msg.turretAng <- CALL p.getTank().getTurretAngle() 2 IF CALL isClient() THEN CALL Client.send(CALL msg.toBuffer()) 3 RETURN true ELSE 4 CALL Host.broadcast(CALL msg.toBuffer()) RETURN false ENDIF END sendTankPosition

Gambar 6.15 Pemodelan algoritma sendTankPosition() ke dalam flow graph Sumber: Pengujian

Pemodelan ke dalam flow graph yang telah dilakukan terhadap operasi sendTankPosition()

menghasilkan

jumlah

kompleksitas

siklomatis

(cyclomatic complexity) melalui persamaan V(G) = E – N + 2 . V(G) = E – N + 2 = 5–5+2 = 2 Dari nilai cyclomatic complexity yang telah dihasilkan dari perhitungan yaitu ditentukan dua buah basis set dari jalur independent yaitu: Jalur 1 : 1 – 2 – 4 – 5 Jalur 2 : 1 – 2 – 3 – 5

94

Proses pengujian untuk operasi sendTankPosition() di klas Manager menggunakan sebuah klas dummy yaitu klas SendTankPositionTest. Atribut dan operasi yang ada dalam klas SendTankPositionTest seperti ditunjukkan dalam Gambar 6.16.

Gambar 6.16 Diagram klas dummy SendTankPositionTest Sumber: Pengujian

Penentuan kasus uji untuk masing-masing jalur dan hasil eksekusi untuk masingmasing kasus uji dijelaskan pada Tabel 6.8. Tabel 6.8 Test case untuk pengujian integrasi operasi sendTankPosition() Jalur 1

Kasus uji Server melakukan pengiriman data posisi tank

Hasil yang diharapkan Server melakukan broadcast data posisi tank ke semua client. Sistem melakukan pemanggilan method Host.broadcast() dan mengembalikan nilai return

Hasil yang didapatkan Server melakukan broadcast data posisi tank ke semua client. Sistem melakukan pemanggilan method Host.broadcast() dan mengembalikan nilai

: false

return : false

2

Client melakukan pengiriman data posisi tank

Client mengirim data posisi tank ke server untuk diforward ke client- client lainnya. Sistem melakukan pemanggilan method Client.send() dan mengembalikan nilai return

Client mengirim data posisi tank ke server untuk di-forward ke client- client lainnya. Sistem melakukan pemanggilan method Client.send() dan mengembalikan nilai

: true

return : true

Sumber: Pengujian

d.

Pengujian Integrasi untuk Operasi updateTankPosition() Operasi updateTankPosition() merupakan implementasi dari

algoritma proses penerimaan dan update

data posisi tank pemain. Operasi

(metode) updateTankPosition() terdapat di dalam klas Manager. Gambar 6.17 memperlihatkan proses pemodelan dalam flow graph pada operasi updateTankPosition().

95

METHOD updateTankPosition PARAMETER message IS boolean

Node (N) = 4 Edge (E) = 4

DECLARATION: TYPE message IS Message msg IS TankPositionMsg p IS Player DESCRIPTION: msg <- (TankPositionMsg) message 1 p <- CALL PlayerList.getPlayer(msg.playerId) IF p != NULL THEN 2 CALL p.getTank().setX(msg.x) CALL p.getTank().setY(msg.y) 3 CALL p.getTank().setBodyAngle(msg.bodyAng) CALL p.getTank().setTurretAngle(msg.turretAng) RETURN true ENDIF 4 RETURN false END updateTankPosition

Gambar 6.17 Pemodelan algoritma updateTankPosition() ke dalam flow graph Sumber: Pengujian

Pemodelan ke dalam flow graph yang telah dilakukan terhadap operasi updateTankPosition()

menghasilkan

jumlah

kompleksitas

siklomatis

(cyclomatic complexity) melalui persamaan V(G) = E – N + 2 . V(G) = E – N + 2 = 4–4+2 = 2 Dari nilai cyclomatic complexity yang telah dihasilkan dari perhitungan yaitu ditentukan dua buah basis set dari jalur independent yaitu: Jalur 1 : 1 – 2 – 3 – 4 Jalur 2 : 1 – 2 – 4 Proses pengujian untuk operasi updateTankPosition() di klas Manager menggunakan sebuah klas dummy yaitu klas UpdateTankPositionTest. Atribut dan operasi yang ada dalam klas UpdateTankPositionTest seperti ditunjukkan dalam Gambar 6.18.

Gambar 6.18 Diagram klas dummy UpdateTankPositionTest Sumber: Pengujian

96

Penentuan kasus uji untuk masing-masing jalur dan hasil eksekusi untuk masingmasing kasus uji dijelaskan pada Tabel 6.9. Tabel 6.9 Test case untuk pengujian integrasi operasi updateTankPosition() Jalur 1

Kasus uji ID pemain yang diterima valid

Hasil yang diharapkan Sistem melakukan update data posisi tank terbaru sesuai dengan ID pemain yang diterima. Method mengembalikan nilai return : true

2

ID pemain yang diterima invalid

Sistem tidak melakukan update data posisi tank terbaru. Method mengembalikan nilai return : false

Hasil yang didapatkan Sistem melakukan update data posisi tank terbaru sesuai dengan ID pemain yang diterima. Method mengembalikan nilai return : true Sistem tidak melakukan update data posisi tank terbaru. Method mengembalikan nilai return : false

Sumber: Pengujian

e.

Pengujian Integrasi untuk Operasi sendFireState() Operasi sendFireState() merupakan implementasi dari algoritma

proses pengiriman pesan notifikasi tembakan pemain. Operasi (metode) sendFireState()

memperlihatkan

terdapat

proses

di

dalam

pemodelan

klas

dalam

Manager.

flow

graph

Gambar pada

sendFireState(). METHOD sendFireState PARAMETER playerId, msgId IS int

DECLARATION: TYPE playerId IS byte msgId IS byte fireBulletMsg IS FireBulletMsg fireRocketMsg IS FireRocketMsg

DESCRIPTION:

6

IF FireBulletMsg.ID == msgId THEN 1 fireBulletMsg = CREATE OBJECT FireBulletMsg() fireBulletMsg.playerId <- playerId 2 IF CALL isClient() THEN 3 CALL Client.send(CALL fireBulletMsg.toBuffer()) RETURN 1 ELSE 4 CALL Host.broadcast(CALL fireBulletMsg.toBuffer()) RETURN 2 5 ENDIF ELSE IF FireRocketMsg.ID == msgId THEN fireRocketMsg = CREATE OBJECT FireRocketMsg() fireRocketMsg.playerId <- playerId 7 IF CALL isClient() THEN CALL Client.send(CALL fireRocketMsg.toBuffer()) 8 RETURN 3 ELSE 9 CALL Host.broadcast(CALL fireRocketMsg.toBuffer()) RETURN 4 ENDIF 10

97

Node (N) = 11 Edge (E) = 14

6.19

operasi

11

ENDIF RETURN 0 END sendFireState

Gambar 6.19 Pemodelan algoritma sendFireState() ke dalam flow graph Sumber: Pengujian

Pemodelan ke dalam flow graph yang telah dilakukan terhadap operasi sendFireState() menghasilkan jumlah kompleksitas siklomatis (cyclomatic

complexity) melalui persamaan V(G) = E – N + 2 . V(G) = E – N + 2 = 14 – 11 + 2 = 5 Dari nilai cyclomatic complexity yang telah dihasilkan dari perhitungan yaitu ditentukan lima buah basis set dari jalur independent yaitu: Jalur 1 : 1 – 2 – 3 – 5 – 11 Jalur 2 : 1 – 2 – 4 – 5 – 11 Jalur 3 : 1 – 6 – 7 – 8 – 10 – 11 Jalur 4 : 1 – 6 – 7 – 9 – 10 – 11 Jalur 5 : 1 – 6 – 11 Proses pengujian untuk operasi sendFireState() di klas Manager menggunakan sebuah klas dummy yaitu klas SendFireStateTest. Atribut dan operasi yang ada dalam klas SendFireStateTest seperti ditunjukkan dalam Gambar 6.20.

Gambar 6.20 Diagram klas dummy SendFireStateTest Sumber: Pengujian

Penentuan kasus uji untuk masing-masing jalur dan hasil eksekusi untuk masingmasing kasus uji dijelaskan pada Tabel 6.10.

98

Tabel 6.10 Test case untuk pengujian integrasi operasi sendFireState() Jalur 1

Kasus uji Client mengirimkan pesan notifikasi tembakan pemain dengan nilai ID pesan “5”

Hasil yang diharapkan Client mengirimkan pesan notifikasi tembakan senjata mesin pemain atau FireBulletMsg ke server untuk di-forward ke clientclient lainnya. Sistem melakukan pemanggilan method Client.send() dan mengembalikan nilai

Hasil yang didapatkan Client mengirimkan pesan notifikasi tembakan senjata mesin pemain atau FireBulletMsg ke server untuk di-forward ke clientclient lainnya. Sistem melakukan pemanggilan method Client.send()dan mengembalikan nilai

return : 1

return : 1

2

Server mengirimkan pesan notifikasi tembakan pemain dengan nilai ID pesan “5”

Server melakukan broadcast pesan notifikasi tembakan senjata mesin pemain atau FireBulletMsg ke semua client. Sistem melakukan pemanggilan method Host.broadcast()dan mengembalikan nilai

Server melakukan broadcast pesan notifikasi tembakan senjata mesin pemain atau FireBulletMsg ke semua client. Sistem melakukan pemanggilan method Host.broadcast()dan mengembalikan nilai

return : 2

return : 2

3

Client mengirimkan pesan notifikasi tembakan pemain dengan nilai ID pesan “6”

Client mengirimkan pesan notifikasi tembakan rudal pemain atau FireRocketMsg ke server untuk di-forward ke client-client lainnya. Sistem melakukan pemanggilan method Client.send()dan mengembalikan nilai

Client mengirimkan pesan notifikasi tembakan rudal pemain atau FireRocketMsg ke server untuk di-forward ke client-client lainnya. Sistem melakukan pemanggilan method Client.send()dan mengembalikan nilai

return : 3

return : 3

Server melakukan broadcast pesan notifikasi tembakan rudal pemain atau FireRocketMsg ke semua client. Sistem melakukan pemanggilan method Host.broadcast()dan mengembalikan nilai

4

Server mengirimkan pesan notifikasi tembakan pemain dengan nilai ID pesan “6”

Server melakukan broadcast pesan notifikasi tembakan rudal pemain atau FireRocketMsg ke semua client. Sistem melakukan pemanggilan method Host.broadcast()dan mengembalikan nilai return : 4

return : 4

5

Nilai ID pesan selain “5” dan “6”

Sistem tidak melakukan pengiriman data. Method mengembalikan nilai return : 0

Sistem tidak melakukan pengiriman data. Method mengembalikan nilai return : 0

Sumber: Pengujian

f.

Pengujian Integrasi untuk Operasi receiveFireState() Operasi

receiveFireState()

merupakan

implementasi

dari

algoritma proses penerimaan pesan notifikasi tembakan pemain. Operasi (metode) receiveFireState() terdapat di dalam klas Manager.

99

Gambar 6.21

memperlihatkan

proses

pemodelan

dalam

flow

graph

pada

operasi

receiveFireState(). METHOD receiveFireState PARAMETER message, msgId IS boolean

Node (N) = 11 Edge (E) = 14

DECLARATION: TYPE message IS Message msgId IS byte fireBulletMsg IS FireBulletMsg fireRocketMsg IS FireRocketMsg p IS Player

2

5 7

10 11

DESCRIPTION: IF FireBulletMsg.ID == msgId THEN 1 fireBulletMsg <- (FireBulletMsg) message p <- CALL PlayerList.getPlayer(fireBulletMsg.playerId) 3 IF p != NULL THEN CALL p.getTank().fireBullet() 4 RETURN true ENDIF RETURN false ELSE IF FireRocketMsg.ID == msgId THEN 6 fireRocketMsg <- (FireRocketMsg) message p <- CALL PlayerList.getPlayer(fireRocketMsg.playerId) 8 IF p != NULL THEN CALL p.getTank().fireRocket() 9 RETURN true ENDIF RETURN false ENDIF RETURN false END receiveFireState

Gambar 6.21 Pemodelan algoritma receiveFireState() ke dalam flow graph Sumber: Pengujian

Pemodelan ke dalam flow graph yang telah dilakukan terhadap operasi receiveFireState()

menghasilkan

jumlah

kompleksitas

siklomatis

(cyclomatic complexity) melalui persamaan V(G) = E – N + 2 . V(G) = E – N + 2 = 14 – 11 + 2 = 5 Dari nilai cyclomatic complexity yang telah dihasilkan dari perhitungan yaitu ditentukan lima buah basis set dari jalur independent yaitu: Jalur 1 : 1 – 2 – 3 – 5 – 11 Jalur 2 : 1 – 2 – 3 – 4 – 5 – 11 Jalur 3 : 1 – 2 – 6 – 11 Jalur 4 : 1 – 2 – 6 – 7 – 8 – 10 – 11 Jalur 5 : 1 – 2 – 6 – 7 – 8 – 9 – 10 – 11

100

Proses pengujian untuk operasi receiveFireState() di klas Manager menggunakan sebuah klas dummy yaitu klas ReceiveFireStateTest. Atribut dan operasi yang ada dalam klas ReceiveFireStateTest seperti ditunjukkan dalam Gambar 6.22.

Gambar 6.22 Diagram klas dummy ReceiveFireStateTest Sumber: Pengujian

Penentuan kasus uji untuk masing-masing jalur dan hasil eksekusi untuk masingmasing kasus uji dijelaskan pada Tabel 6.11. Tabel 6.11 Test case untuk pengujian integrasi operasi receiveFireState() Jalur 1

2

3

4

5

Kasus uji Menerima pesan notifikasi tembakan pemain dengan ID pesan “5” dan ID pemain invalid Menerima pesan notifikasi tembakan pemain dengan ID pesan “5” dan ID pemain valid Nilai ID pesan selain “5” dan “6”

Menerima pesan notifikasi tembakan pemain dengan ID pesan “6” dan ID pemain invalid Menerima pesan notifikasi tembakan pemain dengan ID pesan “6” dan ID pemain valid

Hasil yang diharapkan Sistem tidak melakukan pemanggilan method

Hasil yang didapatkan Sistem tidak melakukan pemanggilan method

fireBullet().

fireBullet().

Method mengembalikan nilai return : false Sistem melakukan pemanggilan method

Method mengembalikan nilai return : false Sistem melakukan pemanggilan method

fireBullet().

fireBullet().

Method mengembalikan nilai return : true Sistem tidak melakukan pengolahan data pesan yang diterima. Method mengembalikan nilai return : false Method tidak melakukan pemanggilan method

Method mengembalikan nilai return : true Sistem tidak melakukan pengolahan data pesan yang diterima. Method mengembalikan nilai return : false Method tidak melakukan pemanggilan method

fireRocket().

fireRocket().

Method mengembalikan nilai return : false Method melakukan pemanggilan method

Method mengembalikan nilai return : false Method melakukan pemanggilan method

fireRocket().

fireRocket().

Method mengembalikan nilai return : true

Method mengembalikan nilai return : true

Sumber: Pengujian

101

g.

Pengujian Integrasi untuk Operasi sendGameState() Operasi sendGameState() merupakan implementasi dari algoritma

proses pengiriman pesan notifikasi status permainan. Operasi (metode) sendGameState()

memperlihatkan

terdapat

proses

di

dalam

pemodelan

klas

dalam

Manager.

flow

graph

Gambar pada

6.23

operasi

sendGameState(). METHOD sendGameState PARAMETER flags IS int

Node (N) = 10 Edge (E) = 13

DECLARATION: TYPE flags IS byte pos IS Map msg IS SessionFlagMsg futures IS Set f IS WriteFuture DESCRIPTION: IF SessionFlagMsg.NEW_ROUND == flags THEN pos <- CALL Util.applyRandomTankPosition() msg <- CREATE OBJECT SessionFlagMsg() msg.flags <- SessionFlagMsg.NEW_ROUND 2 msg.pos <- pos CALL Host.broadcast(CALL msg.toBuffer()) RETURN 2 3 ELSE IF SessionFlagMsg.RESTART_ROUND == flags THEN pos <- CALL Util.applyRandomTankPosition() msg <- CREATE OBJECT SessionFlagMsg() 4 msg.flags <- SessionFlagMsg.RESTART_ROUND CALL Host.broadcast(CALL msg.toBuffer()) RETURN 1 5 ELSE IF SessionFlagMsg.END_SESSION == flags THEN msg <- CREATE OBJECT SessionFlagMsg() 6 msg.flags <- SessionFlagMsg.END_SESSION futures <- CALL Host.broadcast(CALL msg.toBuffer()) 7 FOR f:futures DO CALL f.awaitUninterruptibly(1000) 8 ENDFOR 9 CALL Host.destroy() RETURN 3 ENDIF 10 RETURN 0 END sendGameState 1

Gambar 6.23

Pemodelan algoritma sendGameState() ke dalam flow graph Sumber: Pengujian

Pemodelan ke dalam flow graph yang telah dilakukan terhadap operasi sendGameState() menghasilkan jumlah kompleksitas siklomatis (cyclomatic

complexity) melalui persamaan V(G) = E – N + 2 . V(G) = E – N + 2 = 13 – 10 + 2 = 5 Dari nilai cyclomatic complexity yang telah dihasilkan dari perhitungan yaitu ditentukan lima buah basis set dari jalur independent yaitu:

102

Jalur 1 : 1 – 2 – 10 Jalur 2 : 1 – 3 – 4 – 10 Jalur 3 : 1 – 3 – 5 – 10 Jalur 4 : 1 – 3 – 5 – 6 – 7 – 9 – 10 Jalur 5 : 1 – 3 – 5 – 6 – 7 – 8 - .... Proses pengujian untuk operasi sendGameState() di klas Manager menggunakan sebuah klas dummy yaitu klas SendGameStateTest. Atribut dan operasi yang ada dalam klas SendGameStateTest seperti ditunjukkan dalam Gambar 6.24.

Gambar 6.24 Diagram klas dummy SendGameStateTest Sumber: Pengujian

Penentuan kasus uji untuk masing-masing jalur dan hasil eksekusi untuk masingmasing kasus uji dijelaskan pada Tabel 6.12. Tabel 6.12 Test case untuk pengujian integrasi operasi sendGameState() Jalur 1

Kasus uji Nilai flags sama dengan SessionFlagMsg.NEW_ROUND

atau “2”

2

Nilai flags sama dengan SessionFlagMsg.RESTART_R OUND atau “1”

Hasil yang diharapkan Server melakukan broadcast pesan notifikasi status permainan atau SessionFlagMsg ke semua client dengan nilai flags sama dengan “2”. Sistem melakukan pemanggilan method Host.broadcast() dan mengembalikan nilai

Hasil yang didapatkan Server melakukan broadcast pesan notifikasi status permainan atau SessionFlagMsg ke semua client dengan nilai flags sama dengan “2”. Method melakukan pemanggilan method Host.broadcast()dan mengembalikan nilai

return 2

return 2

Server melakukan broadcast pesan notifikasi status permainan atau SessionFlagMsg ke semua client dengan nilai flags sama dengan “1”. Sistem melakukan

Server melakukan broadcast pesan notifikasi status permainan atau SessionFlagMsg ke semua client dengan nilai flags sama dengan “1”. Method melakukan

103

pemanggilan method Host.broadcast() dan mengembalikan nilai 3

Nilai flags selain “1”, “2”, dan “3”

4

Nilai flags sama dengan SessionFlagMsg.END_SESSI ON atau “3” dan tidak ada client

5

Nilai flags sama dengan SessionFlagMsg.END_SESSI ON atau “3” dan jumlah client lebih dari nol

pemanggilan method Host.broadcast()dan mengembalikan nilai

return 1

return 1

Sistem tidak melakukan pengiriman pesan apapun. Method mengembalikan nilai return 0 Sistem tidak melakukan broadcast pesan notifikasi status permainan karena tidak ada client. Method mengembalikan nilai return 3 Server melakukan broadcast pesan notifikasi status permainan atau SessionFlagMsg ke semua client dengan nilai flags sama dengan “3”. Sistem melakukan pemanggilan method

Sistem tidak melakukan pengiriman pesan apapun. Method mengembalikan nilai return 0 Sistem tidak melakukan broadcast pesan notifikasi status permainan karena tidak ada client Method mengembalikan nilai return 3 Server melakukan broadcast pesan notifikasi status permainan atau SessionFlagMsg ke semua client dengan nilai flags sama dengan “3”. Method melakukan pemanggilan method

Host.broadcast()

Host.broadcast()

Method mengembalikan nilai return 3

Method mengembalikan nilai return 3

Sumber: Pengujian

h.

Pengujian Integrasi untuk Operasi updateGameState() Operasi updateGameState() merupakan implementasi dari algoritma

proses penerimaan pesan notifikasi status permainan. Operasi (metode) updateGameState() terdapat di dalam klas Manager.

Gambar 6.25

memperlihatkan

pada

proses

pemodelan

dalam

flow

graph

operasi

updateGameState(). METHOD updateGameState PARAMETER message IS int DECLARATION: TYPE message IS Message msg IS SessionFlagMsg DESCRIPTION: msg <- (SessionFlagMsg) message IF SessionFlagMsg.NEW_ROUND == msg.flags THEN 2 CALL GameSession.calculateScore() CALL GameSession.roundNotify() 3 CALL GameSession.newRound() CALL Util.updateAllTankPosition(msg.pos) RETURN 2 4 ELSE IF SessionFlagMsg.RESTART_ROUND == msg.flags THEN CALL FlashMessageBox.instance().showFlashMessage(2000, “Round Restarted”) 5 CALL GameSession.restartRound() CALL Util.updateAllTankPosition(msg.pos) RETURN 1 6 ELSE IF SessionFlagMsg.END_SESSION == msg.flags 1

104

Node (N) = 8 Edge (E) = 10

7 8

THEN CALL GameSession.endSession() RETURN 3 ENDIF RETURN 0 END updateGameState

Gambar 6.25 Pemodelan algoritma updateGameState() ke dalam flow graph Sumber: Pengujian

Pemodelan ke dalam flow graph yang telah dilakukan terhadap operasi updateGameState() menghasilkan jumlah kompleksitas siklomatis (cyclomatic

complexity) melalui persamaan V(G) = E – N + 2 . V(G) = E – N + 2 = 10 – 8 + 2 = 4 Dari nilai cyclomatic complexity yang telah dihasilkan dari perhitungan yaitu ditentukan empat buah basis set dari jalur independent yaitu: Jalur 1 : 1 – 2 – 3 – 8 Jalur 2 : 1 – 2 – 4 – 5 – 8 Jalur 3 : 1 – 2 – 4 – 6 – 7 – 8 Jalur 4 : 1 – 2 – 4 – 6 – 8 Proses pengujian untuk operasi updateGameState() di klas Manager menggunakan sebuah klas dummy yaitu klas UpdateGameStateTest. Atribut dan operasi yang ada dalam klas UpdateGameStateTest seperti ditunjukkan dalam Gambar 6.26.

Gambar 6.26 Diagram klas dummy UpdateGameStateTest Sumber: Pengujian

Penentuan kasus uji untuk masing-masing jalur dan hasil eksekusi untuk masingmasing kasus uji dijelaskan pada Tabel 6.13.

105

Tabel 6.13 Test case untuk pengujian integrasi operasi updateGameState() Jalur 1

Kasus uji Nilai flags sama dengan SessionFlagMsg.NEW_ROUND

atau “2”

2

Nilai flags sama dengan SessionFlagMsg.RESTART_R OUND atau “1”

3

Nilai flags sama dengan SessionFlagMsg.END_SESSI ON atau “3”

4

Nilai flags selain “1”, “2”, dan “3”

Hasil yang diharapkan Sistem memulai ronde yang baru. Sistem melakukan pemanggilan method

Hasil yang didapatkan Sistem memulai ronde yang baru. Sistem melakukan pemanggilan method

GameSession.newRound()

GameSession.newRound()

dan mengembalikan nilai

dan mengembalikan nilai

return 2

return 2

Sistem melakukan pengulangan ronde. Sistem melakukan pemanggilan method

Sistem melakukan pengulangan ronde. Sistem melakukan pemanggilan method

GameSession.restartRou nd() dan mengembalikan nilai return 1

GameSession.restartRou nd() dan mengembalikan nilai return 1

Sistem memberhentikan session yang aktif. Sistem melakukan pemanggilan method

Sistem memberhentikan session yang aktif. Sistem melakukan pemanggilan method

GameSession.endSession () dan mengembalikan nilai return 3

GameSession.endSession () dan mengembalikan nilai return 3

Sistem tidak mengolah pesan yang diterima dan mengembalikan nilai

Sistem tidak mengolah pesan yang diterima dan mengembalikan nilai

return 0

return 0

Sumber: Pengujian

6.1.3

Pengujian Validasi Pengujian validasi digunakan untuk mengetahui apakah sistem yang

dibangun sudah benar sesuai dengan yang dibutuhkan. Item-item yang telah dirumuskan dalam daftar kebutuhan dan merupakan hasil analisis kebutuhan akan menjadi acuan untuk melakukan pengujian validasi. Pengujian validasi menggunakan metode pengujian Black Box, karena tidak memerlukan untuk berkonsentrasi terhadap alur jalannya algoritma program dan lebih ditekankan untuk menemukan konformitas antara kinerja sistem dengan daftar kebutuhan. Pada skripsi ini dilakukan pengujian validasi terhadap subsistem game server. 6.1.3.1 Kasus Uji Validasi a.

Kasus Uji Pencarian Sesi Permainan Yang Aktif Nama Kasus Uji

: Kasus Uji Pencarian Sesi Permainan Yang Aktif

106

Objek Uji

: Kebutuhan Fungsional (F08)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk pencarian sesi permainan yang aktif sehingga pengguna dapat mengetahui sesi atau server permainan yang aktif dalam LAN (Local Area Network)

Prosedur Uji

: 1. Menekan tombol “scan server” pada menu join game

Hasil yang

: Aplikasi dapat menampilkan informasi server

diharapkan

atau sesi permainan yang aktif dalam LAN (Local Area Network)

b. Kasus Uji Penggabungan Dengan Sesi Permainan Nama Kasus Uji

: Kasus

Uji

Penggabungan

Dengan

Sesi

Permainan Objek Uji

: Kebutuhan Fungsional (F09)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk melakukan penggabungan dengan sebuah sesi permainan yang aktif atau melakukan koneksi ke sebuah game server sehingga pengguna

dapat

aktif

dalam

sebuah

sesi

permainan dan mulai melakukan permainan. Prosedur Uji

: 1. Memasukkan nilai alamat IP game server pada server IP textfield dan nilai password pada password textfield. Serta memilih tim dan karakter (tank) pemain pada menu join game. Kemudian menekan tombol “ok”

Hasil yang

: Aplikasi dapat melakukan koneksi ke game

diharapkan

server dan pengguna dapat aktif dalam sebuah

107

sesi permainan dan mulai melakukan permainan c.

Kasus Uji Pembuatan Sesi Permainan Nama Kasus Uji

: Kasus Uji Pembuatan Sesi Permainan

Objek Uji

: Kebutuhan Fungsional (F10)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk melakukan proses pembuatan sebuah sesi permainan sehingga dapat membuah sebuah sesi permainan yang baru dan mengaktifkan sebuah game server.

Prosedur Uji

: 1. Memasukkan nilai password pada password textfield dan nilai batas maksimum pemain dalam sebuah sesi permainan pada max player textfield. Serta memilih tim dan karakter (tank) pemain pada menu create game. Kemudian menekan tombol “ok”.

Hasil yang

: Aplikasi dapat membuat sebuah sesi permainan

diharapkan

yang baru dan mengaktifkan sebuah game server.

d. Kasus Uji Pengiriman Chat Nama Kasus Uji

: Kasus Uji Pengiriman Chat

Objek Uji

: Kebutuhan Fungsional (F26)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk

melakukan

pengiriman

pesan

chat

sehingga pemain dapat mengirimkan pesan chat ke semua pemain lainnya. Prosedur Uji

: 1. Memasukkan pesan chat dalam chat box dan menekan tombol keyboard “ENTER” ketika berada di ingame state.

Hasil yang

: Aplikasi dapat mengirimkan pesan chat ke

108

diharapkan

semua pemain yang aktif dalam sebuah sesi permainan.

e.

Kasus Uji Penerimaan Chat Nama Kasus Uji

: Kasus Uji Penerimaan Chat

Objek Uji

: Kebutuhan Fungsional (F27)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk

melakukan

penerimaan

pesan

chat

sehingga semua pemain dapat mengetahui pesan chat yang masuk terdeteksi oleh sistem. Prosedur Uji

: 1. Sistem mendeteksi adanya pesan chat yang masuk. 2. Sistem menambahkan Pesan chat ke dalam chat list untuk ditampilkan pada chat board.

Hasil yang diharapkan f.

: Aplikasi dapat menerima dan mengolah pesan chat yang diterima dari pemain.

Kasus Uji Pengiriman Notifikasi Update Tim dan Tank Nama Kasus Uji

: Kasus Uji Pengiriman Notifikasi Update Tim dan Tank

Objek Uji

: Kebutuhan Fungsional (F28)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk pengiriman notifikasi update tim dan tank pemain sehingga pemain dapat mengirimkan pesan

notifikasi

ketika

pemain

tersebut

melakukan update tim dan tank. Prosedur Uji

: 1. Memilih tim dan tank pada dialog ganti tim dan tank, kemudian menekan tombol “Ok” ketika berada di ingame state.

Hasil yang

: Aplikasi dapat mengirimkan pesan notifikasi

109

diharapkan

update tim dan tank pemain ke semua pemain lainnya.

g.

Kasus Uji Penerimaan Notifikasi Update Tim dan Tank Nama Kasus Uji

: Kasus Uji Penerimaan Notifikasi Update Tim dan Tank

Objek Uji

: Kebutuhan Fungsional (F29)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk penerimaan notifikasi update tim dan tank pemain

sehingga

semua

pemain

dapat

mengetahui informasi update tim dan tank pemain lain. Prosedur Uji

: 1. Sistem mendeteksi adanya pesan notifikasi update tim dan tank yang masuk. 2. Sistem memperbarui informasi tim dan tank pemain.

Hasil yang diharapkan

: Aplikasi dapat menerima dan mengolah pesan notifikasi update tim dan tank pemain.

h. Kasus Uji Pengiriman Notifikasi Update Nama Pemain Nama Kasus Uji

: Kasus Uji Pengiriman Notifikasi Update Nama Pemain

Objek Uji

: Kebutuhan Fungsional (F30)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk pengiriman notifikasi update nama pemain sehingga pemain dapat mengirimkan pesan notifikasi ketika pemain tersebut melakukan update nama.

Prosedur Uji

: 1. Memperbarui nama pemain dalam dialog opsi dan menekan tombol “Ok” ketika berada

110

di ingame state. Hasil yang diharapkan i.

: Aplikasi dapat mengirimkan pesan notifikasi update nama pemain.

Kasus Uji Penerimaan Notifikasi Update Nama Pemain Nama Kasus Uji

: Kasus Uji Penerimaan Notifikasi Update Nama Pemain

Objek Uji

: Kebutuhan Fungsional (F31)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk penerimaan notifikasi update nama pemain sehingga semua pemain dapat mengetahui informasi update nama pemain lain.

Prosedur Uji

: 1. Sistem mendeteksi adanya pesan notifikasi update nama pemain yang masuk. 2. Sistem memperbarui data nama seorang pemain.

Hasil yang diharapkan j.

: Aplikasi dapat menerima dan mengolah pesan notifikasi update nama pemain yang masuk.

Kasus Uji Pengiriman Posisi Tank Nama Kasus Uji

: Kasus Uji Pengiriman Posisi Tank

Objek Uji

: Kebutuhan Fungsional (F32)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk pengiriman posisi tank sehingga pemain dapat mengirimkan posisi tank terbarunya.

Prosedur Uji

: 1. Menggerakkan tank dengan tombol keyboard “A”,

“D”,

ARROW”, ARROW”.

111

“UP “RIGHT

ARROW”, ARROW”,

“DOWN “LEFT

Hasil yang diharapkan

: Aplikasi dapat mengirimkan posisi tank terbaru pemain ke semua pemain lain.

k. Kasus Uji Penerimaan Update Posisi Tank Nama Kasus Uji

: Kasus Uji Penerimaan Update Posisi Tank

Objek Uji

: Kebutuhan Fungsional (F33)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk penerimaan update posisi tank sehingga semua pemain dapat mengetahui data posisi tank terbaru pemain lain.

Prosedur Uji

: 1. Sistem mendeteksi adanya data posisi tank terbaru yang masuk. 2. Sistem memperbarui data posisi tank.

Hasil yang diharapkan l.

: Aplikasi dapat menerima dan mengolah data posisi tank terbaru yang masuk.

Kasus Uji Pengiriman Fire State Nama Kasus Uji

: Kasus Uji Pengiriman Fire State

Objek Uji

: Kebutuhan Fungsional (F34)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk pengiriman pesan fire state sehingga pemain dapat

mengirimkan pesan notifikasi

ketika pemain tersebut menembakkan senjata mesin atau rudal. Prosedur Uji

: 1. Menekan tombol keyboard “W” untuk menembakkan senjata mesin atau tombol keyboard “S” untuk menembakkan rudal.

Hasil yang

: Aplikasi dapat mengirimkan pesan notifikasi

diharapkan

ketika pemain menembakkan senjata senjata mesin atau rudal.

112

m. Kasus Uji Penerimaan Fire State Nama Kasus Uji

: Kasus Uji Penerimaan Fire State

Objek Uji

: Kebutuhan Fungsional (F35)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk penerimaan pesan fire state sehingga semua pemain dapat mengetahui notifikasi ketika seorang pemain menembakkan senjata mesin atau rudal.

Prosedur Uji

: 1. Sistem mendeteksi adanya pesan fire state yang masuk. 2. Sistem membuat tank pemain menembakkan senjata mesin atau rudal.

Hasil yang

: Aplikasi dapat menerima dan mengolah pesan

diharapkan

notifikasi ketika pemain menembakkan senjata mesin atau rudal yang masuk.

n. Kasus Uji Memperbarui Ronde Nama Kasus Uji

: Kasus Uji Memperbarui Ronde

Objek Uji

: Kebutuhan Fungsional (F40)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk melakukan perbaruan ronde permainan.

Prosedur Uji

: 1. Menekan tombol keyboard “N”.

Hasil yang

: Aplikasi dapat memperbarui ronde permainan.

diharapkan o.

Kasus Uji Pengulangan Ronde Nama Kasus Uji

: Kasus Uji Pengulangan Ronde

Objek Uji

: Kebutuhan Fungsional (F41)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional

113

untuk melakukan pengulangan ronde permainan yang sedang berlangsung. Prosedur Uji

: 1. Menekan tombol keyboard “R”.

Hasil yang

: Aplikasi dapat mengulangi ronde permainan

diharapkan r.

yang sedang berlangsung.

Kasus Uji Pengiriman Notifikasi Ganti Peta Nama Kasus Uji

: Kasus Uji Pengiriman Notifikasi Ganti Peta

Objek Uji

: Kebutuhan Fungsional (F42)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk pengiriman notifikasi ganti peta sehingga aplikasi dapat mengirimkan pesan notifikasi ketika creator mengganti peta permainan.

Prosedur Uji

: 1. Mengganti peta pada dialog ganti peta permainan,

kemudian

menekan

tombol

keyboard “Ok” ketika berada di ingame state. Hasil yang

: Aplikasi dapat mengirimkan pesan notifikasi

diharapkan

ketika creator mengganti peta permainan ke semua joiner.

s.

Kasus Uji Mengakhiri Sesi Permainan Nama Kasus Uji

: Kasus Uji Mengakhiri Sesi Permainan

Objek Uji

: Kebutuhan Fungsional (F43)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk mengakhiri sesi permainan sehingga aplikasi dapat mengakhiri sesi permainan dan game server dimatikan.

Prosedur Uji

: 1. Menekan

tombol

“Yes”

pada

konfrmasi mengakhiri sesi permainan.

114

dialog

Hasil yang diharapkan t.

: Aplikasi dapat mengakhiri sesi permainan dan mematikan game server.

Kasus Uji Pengiriman Notifikasi Status Permainan Nama Kasus Uji

: Kasus

Uji

Pengiriman

Notifikasi

Status

Permainan Objek Uji

: Kebutuhan Fungsional (F44)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk pengiriman notifikasi status permainan sehingga aplikasi dapat mengirimkan notifikasi status permainan ke semua pemain yang aktif dalam sebuah sesi permainan.

Prosedur Uji

: 1. Menekan tombol “R” atau “N”

Hasil yang

: Aplikasi dapat mengirimkan notifikasi status

diharapkan

permainan ke semua pemain yang aktif dalam sebuah sesi permainan.

u. Kasus Uji Meninggalkan Sesi Permainan Nama Kasus Uji

: Kasus Uji Meninggalkan Sesi Permainan

Objek Uji

: Kebutuhan Fungsional (F46)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk meninggalkan sesi permainan sehingga aplikasi dapat mengirimkan pesan permintaan keluar dari sesi permainan joiner ke creator .

Prosedur Uji

: 1. Menekan

tombol

“Yes”

pada

dialog

konfirmasi meninggalkan sesi permainan. Hasil yang diharapkan

: Aplikasi dapat mengirimkan pesan permintaan keluar dari sesi permainan joiner ke creator .

115

v.

Kasus Uji Penerimaan Notifikasi Ganti Peta Nama Kasus Uji

: Kasus Uji Penerimaan Notifikasi Ganti Peta

Objek Uji

: Kebutuhan Fungsional (F47)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk penerimaan notifikasi ganti peta sehingga aplikasi dapat menerima pesan notifikasi ganti peta dari creator.

Prosedur Uji

: 1. Sistem mendeteksi adanya pesan notifikasi ganti peta dari creator yang masuk. 2. Sistem memperbarui peta permainan.

Hasil yang diharapkan

: Aplikasi dapat menerima pesan notifikasi ganti peta dari creator.

w. Kasus Uji Penerimaan Notifikasi Pemain Yang Keluar Nama Kasus Uji

: Kasus Uji Penerimaan Notifikasi Pemain Yang Keluar

Objek Uji

: Kebutuhan Fungsional (F36)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk penerimaan notifikasi pemain yang keluar sehingga

aplikasi

dapat

menerima

pesan

notifikasi ketika ada seorang pemain keluar dari sesi permainan. Prosedur Uji

: 1. Sistem mendeteksi adanya pesan notifikasi pemain yang keluar yang masuk. 2. Sistem menghapus data pemain yang keluar dari sesi permainan.

Hasil yang

: Aplikasi dapat menerima pesan notifikasi ketika

diharapkan

ada seorang pemain keluar dari sesi permainan dan menghapus data pemain tersebut.

116

x.

Kasus Uji Penerimaan Notifikasi Pemain Baru Nama Kasus Uji

: Kasus Uji Penerimaan Notifikasi Pemain Baru

Objek Uji

: Kebutuhan Fungsional (F37)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk

penerimaan

sehingga

aplikasi

notifikasi dapat

pemain

menerima

baru pesan

notifikasi ketika ada seorang pemain yang baru bergabung dalam sebuah sesi permainan. Prosedur Uji

: 1. Sistem mendeteksi adanya pesan notifikasi pemain baru yang masuk 2. Sistem menambahkan data pemain baru dalam daftar pemain yang aktif.

Hasil yang

: Aplikasi dapat menerima pesan notifikasi ketika

diharapkan

ada seorang pemain yang baru bergabung dalam sebuah sesi permainan dan menambahkan data pemain baru tersebut dalam daftar pemain yang aktif.

y.

Kasus Uji Penerimaan Notifikasi Status Permainan Nama Kasus Uji

: Kasus

Uji

Penerimaan

Notifikasi

Status

Permainan Objek Uji

: Kebutuhan Fungsional (F48)

Tujuan Pengujian

: Pengujian dilakukan untuk memastikan bahwa aplikasi dapat memenuhi kebutuhan fungsional untuk penerimaan notifikasi status permainan sehingga

aplikasi

dapat

menerima

pesan

notifikasi ketika creator melakukan update status permainan. Prosedur Uji

: 1. Sistem mendeteksi adanya pesan notifikasi status permainan yang masuk.

117

2. Sistem melakukan update status permainan. Hasil yang

: Aplikasi dapat menerima dan mengolah pesan

diharapkan

notifikasi ketika creator melakukan update status permainan.

6.1.3.2 Hasil Pengujian Validasi Dari kasus uji yang telah dilaksanakan sesuai dengan prosedur pengujian pada sub pokok bahasan 6.1.3.1, didapatkan hasil seperti ditunjukkan pada Tabel 6.14. Tabel 6.14 Test case untuk pengujian validasi No 1

2

Kasus Uji Pencarian

Hasil yang didapatkan

Status

Sesi Aplikasi dapat menampilkan informasi server

Permainan

atau sesi permainan yang aktif dalam LAN

Yang Aktif

(Local Area Network)

Penggabungan

Aplikasi dapat melakukan koneksi ke game

Dengan Permainan

Valid

Valid

Sesi server dan pengguna dapat aktif dalam sebuah sesi

permainan

dan

mulai

melakukan

permainan 3

Pembuatan Sesi Aplikasi Permainan

dapat

membuat

sebuah

sesi

Valid

permainan yang baru dan mengaktifkan sebuah game server

4

Pengiriman

Aplikasi dapat mengirimkan pesan chat ke

Chat

semua pemain yang aktif dalam sebuah sesi

Valid

permainan 5

6

Penerimaan

Aplikasi dapat menerima dan mengolah pesan

Chat

chat yang diterima dari pemain

Pengiriman

Aplikasi dapat mengirimkan pesan notifikasi

Notifikasi

update tim dan tank pemain ke semua pemain

Update Tim dan lainnya

118

Valid

Valid

Tank 7

Penerimaan

Aplikasi dapat menerima dan mengolah pesan

Notifikasi

notifikasi update tim dan tank pemain

Valid

Update Tim dan Tank 8

Pengiriman

Aplikasi dapat mengirimkan pesan notifikasi

Notifikasi

update nama pemain

Update

Valid

Nama

Pemain 9

Penerimaan

Aplikasi dapat menerima dan mengolah pesan

Notifikasi

notifikasi update nama pemain yang masuk

Update

Valid

Nama

Pemain 10

11

Pengiriman

Aplikasi dapat mengirimkan posisi tank

Posisi Tank

terbaru pemain ke semua pemain lain

Penerimaan

Aplikasi dapat menerima dan mengolah data

Update

Valid

Valid

Posisi posisi tank terbaru yang masuk

Tank 12

Pengiriman Fire Aplikasi dapat mengirimkan pesan notifikasi State

Valid

ketika pemain menembakkan senjata senjata mesin atau rudal

13

Penerimaan

Aplikasi dapat menerima dan mengolah pesan

Fire State

notifikasi

ketika

pemain

Valid

menembakkan

senjata mesin atau rudal yang masuk 14

Memperbarui

Aplikasi dapat memperbarui ronde permainan

Valid

Pengulangan

Aplikasi dapat mengulangi ronde permainan

Valid

Ronde

yang sedang berlangsung

Pengiriman

Aplikasi dapat mengirimkan pesan notifikasi

Ronde 15

16

119

Valid

Notifikasi Ganti ketika creator mengganti peta permainan ke Peta 17

18

semua joiner.

Mengakhiri Sesi Aplikasi dapat mengakhiri sesi permainan dan Permainan

mematikan game server

Pengiriman

Aplikasi dapat mengirimkan notifikasi status

Notifikasi

permainan ke semua pemain yang aktif dalam

Status

sebuah sesi permainan

Valid

Valid

Permainan 19

Meninggalkan

Aplikasi

dapat

mengirimkan

pesan

Sesi Permainan

permintaan keluar dari sesi permainan joiner

Valid

ke creator 20

Penerimaan

Aplikasi dapat menerima pesan notifikasi

Valid

Notifikasi Ganti ganti peta dari creator Peta 21

Penerimaan

Aplikasi dapat menerima pesan notifikasi

Notifikasi

ketika ada seorang pemain keluar dari sesi

Pemain

22

Valid

Yang permainan dan menghapus data pemain

Keluar

tersebut

Penerimaan

Aplikasi dapat menerima pesan notifikasi

Notifikasi

ketika

Pemain Baru

bergabung dalam sebuah sesi permainan dan

ada

seorang

pemain

yang

Valid

baru

menambahkan data pemain baru tersebut dalam daftar pemain yang aktif 23

Penerimaan

Aplikasi dapat menerima dan mengolah pesan

Notifikasi

notifikasi ketika creator melakukan update

Status

status permainan

Permainan Sumber: Pengujian

120

Valid

6.2

Pengujian Nilai Throughput Data Game Server Pengujian nilai throughput data game server pada sistem ini ditujukan

untuk mengetahui nilai throughput data yang diterima (Read Bytes Throughput) dan data yang dikirim (Written Bytes Throughput). Dalam percobaan digunakan 10 buah komputer dengan 1 buah komputer sebagai game server dan 9 buah komputer sebagai game client. Spesifikasi hardware komputer game server yang digunakan dalam pengujian dijelaskan pada Tabel 6.15. Tabel 6.15 Spesifikasi perangkat keras komputer Nama Komponen Prosesor Memori (RAM) Hardisk Mother Board Kartu Grafis

Spesifikasi Intel Core 2 Duo Prosesor 2,2 Ghz e4500 512 MB DDR2 Maxtor STM380215as, kapasitas 80 GB, 7200 rpm ASUS P5GC-MX/1333 Intel 82945g Express Sumber: Pengujian

Nilai throughput data game server dihasilkan dari benchmark menggunakan profiler yang disediakan oleh Apache MINA (Multipurpose Infrastructure for Networked Applications) Framework. Adapun perhitungan yang digunakan untuk menentukan nilai throughput data game server adalah sebagai berikut : Read Bytes Throughput =

Read Bytes – Last Read Bytes (bytes) Current Time – Last Throughput Calculation Time (s)

Written Bytes Throughput =

Written Bytes – Last Written Bytes (bytes) Current Time – Last Throughput Calculation Time (s)

Hasil pengujian nilai throughput data game server yang didapatkan dijelaskan pada Tabel 6.16.

121

Tabel 6.16

Nilai Throughput Data Game Server

Average Throughput

Clients

(bytes/s) Read

Written

Bytes

Bytes

1

51,18

870,66

2

111,32

1918,06

3

164,35

2815,67

4

231,53

3904,36

5

337,28

4764,69

6

379,99

5777,92

7

510,03

6699,25

8

556,14

7711,26

9

669,34

8652,98

Nilai Throughput Data Game Server A verag e T h ro u g h p u t (b ytes/s)

# Of

10000 8000 6000 4000 2000 0 1

2

3

4

5

6

7

8

9

# Of Clients Read Bytes Throughput

Written Bytes Throughput

Sumber: Pengujian

Dari Tabel 6.16 diketahui beda nilai read bytes throughput dan written bytes throughput antara satu dengan lainnya tidak tetap. Jadi dapat disimpulkan bahwa nilai read bytes throughput dan written bytes throughput game server tidak linier karena tidak memenuhi persamaan linier y=ax+b. Ketidaklinieran tersebut disebabkan aktivitas pemain yang berbeda sehingga mempengaruhi banyaknya data yang dikirim dan diterima.

122

BAB VII PENUTUP 7.1.

Kesimpulan Berdasarkan hasil perancangan dan pengujian yang dilakukan, maka

diambil kesimpulan sebagai berikut: 1. Perancangan subsistem game server yang bertipe listen server ini menggunakan bahasa pemodelan UML (Unified Modelling Language) dan

diimplementasikan

networking

framework

menggunakan yang

bahasa

digunakan

pemrograman

adalah

Apache

Java, MINA

(Multipurpose Infrastructure for Networked Applications) Framework, protokol jaringan yang digunakan adalah UDP (User Datagram Protocol), serta format data yang digunakan adalah over-the-wire event format. 2. Hasil pengujian nilai throughput data pada game server yang dilakukan menggunakan 10 buah komputer dengan konfigurasi 1 buah komputer sebagai game server dan 9 buah komputer sebagai game client menunjukkan bahwa nilai read bytes throughput dan written bytes throughput tidak linier. Ketidaklinieran tersebut disebabkan aktivitas pemain yang berbeda sehingga mempengaruhi banyaknya data yang dikirim dan diterima. 3. Subsistem game server yang bertipe listen server ini berhasil diintegrasikan dengan subsistem game client, hasil skripsi yang berjudul “Pengembangan 2D Game Client Untuk Multiplayer Tank Game Menggunakan Teknologi Java” oleh Murti Daryandono (Teknik Elektro Universitas Brawijaya, 2008) menjadi sebuah Multiplayer Tank Game. 7.2.

Saran Saran yang dapat diberikan untuk pengembangan subsistem ini antara

lain : 1. Untuk pengembangan lebih lanjut subsistem game server ini dapat dikembangkan untuk massive multiplayer online game. 2. Untuk pengembangan lebih lanjut subsistem ini dapat digunakan teknik dead reckoning.

123

DAFTAR PUSTAKA [ADA-03]

Adams, Ernest. 2003. Break into the Game Industry: How to Get A Job Making Video Games. Mc Graw-Hill/Osborne.

[ALH-03]

Alhir, Sinan Si. 2003. Learning UML O’Reilly.

[ANO-08]

Anonymous.

2008.

Game

Server.

Akses

dari

:

http://en.wikipedia.org/wiki/Game_server . Tanggal Akses : 11 Maret 2008. [ARM-06]

Armitage, Grenville, Mark Claypool, Philip Branch . 2006. Networking and Online Games: Understanding and Engineering Multiplayer Internet Game. John Wiley & Sons.

[ARO-08]

Aronson, Jesse. 2008. Using Groupings for Networked Gaming. Akses dari http://gamasutra.com/features/20000621/. Tanggal Akses : 03 November 2008.

[BRA-03]

Brackeen , David , Bret Barker , Laurence

Vanhelsuwé . 2003.

Developing Games In Java. New Riders Publishing. [BOO-05]

Booch, Grady, James Rumbaugh, Ivar Jacobson. 2005. The Unified Modelling Language User Guide, Second Edition. Addison Wesley.

[CLI-04]

Clingman, Dustin, Shawn Kendall, Syrus Mesdaghi. 2004. Practical Java Game Programming. Charles River Media.

[FOW-02]

Fowler, Martin et al. 2002.

Patterns of Enterprise Application

Architecture. Addison Wesley. [FOW-03]

Fowler, Martin. 2003. UML Distilled : A Brief Guide to the Standard Object Modelling, Third Edition. Addison Wesley.

[KNO-01]

Knoernschild, Kirk. 2001. Java Design : Objects, UML, and Process. Addison Wesley.

[MOR-05]

Morelli, Ralph , Ralph Walde 2005. Java, Java, Java: Object-Oriented Problem Solving, Third Edition. Prentice Hall.

[HAR-04]

Harold, Elliotte Rusty. 2004. Java Network Programming, Third Edition. O’Reilly.

[PIL-05]

Pilone, Dan, Neil Pitman. 2005. UML 2.0 in a Nutshell. O’Reilly.

[PRE-01]

Pressman, Roger S. 2001. Software Engineering : A Practitioner’s Approach, Fifth Edition. McGraw Hill.

[TAN-03]

Tanenbaum, Andrew S. 2003. Computer Networks, Fourth Edition.

124

Prentice Hall. [ZAK-06]

Zakhour, Sharon et al. 2006. The Java Tutorial Fourth Edition : A Short Course on Basics. Addison Wesley.

125