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

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. NIP. 132 149 320

Ir. Muhammad Aswin, MT. 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.

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

DAFTAR ISI

PENGANTAR……….. i

DAFTAR ISI……….... iii

DAFTAR TABEL……….... vii

DAFTAR GAMBAR………... ix

DAFTAR ISTILAH………. xii

ASBTRAK……… xiv I 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 II DASAR TEORI………... 7 2.1 Game Networking……….. 7

2.1.1 Game Networking Protocol……….. 8

2.1.2 Game Networking Process……… 10

2.2 Protokol Komunikasi Jaringan………... 10

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

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

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

2.5.4 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

III 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

IV 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

4.2 Perancangan Perangkat Lunak……… 53

4.2.1 Perancangan Umum... 54

4.2.1.1 Model Komunikasi Data Pada Multiplayer Tank Game... 54 4.2.1.2 Perancangan Umum Subsistem Game Server 55 4.2.2 Perancangan Detail... 57

4.2.2.1 Diagram Klas (Class Diagram)... 57

4.2.2.2 Diagram Sekuensial (Sequence Diagram)... 60

V IMPLEMENTASI……… 68

5.1 Spesifikasi Subsistem... 68

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 Status Permainan... 77

5.4.8 Implementasi Algoritma Menerima Notifikasi Status Permainan... 78 5.4.9 Implementasi Algoritma Mengakhiri Sesi Permainan.. 79

5.4.10 Implementasi Algoritma Meninggalkan Sesi Permainan... 80

5.5 Kendala dalam Implementasi... 81

VI 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

6.2 Pengujian Nilai Throughput Data Game Server... 121

VII PENUTUP... 123

7.1 Kesimpulan... 123

7.2 Saran... 123

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 ... ₄₂

Tabel 4.9 Skenario use case Menerima Notifikasi Update Tim dan Tank 43 Tabel 4.10 Skenario use case Mengirimkan Notifikasi Update Nama Pemain ... ₄₄

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.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()... ₉₅

Tabel 6.9 _{Test case untuk pengujian integrasi operasi} updateTankPosition()... ₉₇

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

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

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

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

Tabel 6.14 Test case untuk pengujian validasi ... 118

Tabel 6.15 Spesifikasi perangkat keras komputer ... 121

DAFTAR GAMBAR

Gambar 2.1 Latency air untuk melewati sebuah selang yang ditentukan

panjang selang... 7

Gambar 2.2 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... 58

Gambar 4.6 Diagram klas anggota paket net.java.dev.boombat.multiplayer.core... 59

Gambar 4.7 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.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... 77

Gambar 5.8 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.12 Diagram klas dummy JoinGameTest... 91 Gambar 6.13 Pemodelan algoritma createGame() ke dalam flow

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... 96 Gambar 6.18 Diagram klas dummy UpdateTankPositionTest... 96 Gambar 6.19 Pemodelan algoritma sendFireState() ke dalam flow

graph... 97 Gambar 6.20 Diagram klas dummy SendFireStateTest... 98 Gambar 6.21 Pemodelan algoritma receiveFireState() ke dalam

flow graph... 100

Gambar 6.22 Diagram klas dummy ReceiveFireStateTest... 101 Gambar 6.23 Pemodelan algoritma sendGameState() ke dalam flow

graph... 102 Gambar 6.24 Diagram klas dummy SendGameStateTest... 103 Gambar 6.25 Pemodelan algoritma updateGameState() ke dalam

flow graph... 104 Gambar 6.26 Diagram klas dummy UpdateGameStateTest... 105

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 Online game

Game yang dimainkan oleh pemain dalam jumlah banyak melalui Internet.

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

Multiplayer Game Game yang dimainkan oleh beberapa pemain. Over-the-wire event

Format

Format data yang berurutan dalam network buffer 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.

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.

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.

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].

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.

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).

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 perangkat lunak, implementasi perangkat lunak, pengujian dan analisis, serta pengambilan kesimpulan dan saran.

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.

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]

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 protocol menurut cara

bersinkronisasi dibagi menjadi dua yaitu, Lock-step dan Open-Loop Synchronization. Sedangkan menurut cara 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

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

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. [TAN-03: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

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.

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.

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.

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

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.

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 kelas-kelas 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.

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

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 whole-part relationship. Hubungan ini dapat dibaca sebagai “…is whole-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).

• 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,

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

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).

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

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 :

• 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 ? 2.5.4.2 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 [PRE-01: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

(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]

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]

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 [PRE-01:490].

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

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 dicapai melalui sederetan pengujian black-box yang memperlihatkan konformitas dengan persyaratan. Rencana 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].

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

• Analisis Kebutuhan (Requirement Analysis) • Perancangan (Design)

• Implementasi • Pengujian (Testing)

3.2 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 kebutuhan-kebutuhan dan fungsionalitas sistem dari perspektif end-user. Analisis kebutuhan-kebutuhan

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 :

• 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. 3.4 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).

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.