Implementasi Algoritma Fuzzy Logic Pada Tingkat Kesulitan Permainan Evakuasi Korban Banjir

SKRIPSI

Diajukan untuk Menempuh Ujian Akhir Sarjana

TIO ADITAMA

10109323

PROGRAM STUDI TEKNIK INFORMATIKA

FAKULTAS TEKNIK DAN ILMU KOMPUTER

UNIVERSITAS KOMPUTER INDONESIA

2014

Nama : Tio Aditama Jenis Kelamin : Laki - Laki

Tempat, Tanggal Lahir : Banyumas, 24 Febuari 1991 Kewarganegaraan : Indonesia

Status Perkawinan : Belum Menikah Tinggi, Berat Badan : 167 cm, 50kg

Kesehatan : Baik

Agama : Islam

Alamat Lengkap : Jalan Jaksa Naranata (Komp. Taman Baleendah Mas No 18) RT 07 / RW 10, Kec Baleendah, Kab Bandung, Prov Jawa Barat.

Telepon, HP : 085351155523

Email : tyoaditama2@gmail.com

2. Riwayat Pendidikan

1997 – 2003 : SDN CIPTAWINAYA 2003 – 2006 : SMPN 2 Baleendah 2006 – 2009 : SMA BPI 3 Bandung

2009 – 2014 : Program Strata Satu (S1) Program Studi Teknik Informatika, Universitas Komputer Indonesia Bandung

v

ABSTRACT ... ii

KATA PENGANTAR ... iii

DAFTAR ISI ... v

DAFTAR GAMBAR ... viii

DAFTAR TABEL ... xi

DAFTAR SIMBOL ... xiii

DAFTAR LAMPIRAN ... xvi

BAB I PENDAHULUAN ... 1

1.2 Latar Belakang Masalah ... 1

1.3 Rumusan Masalah... 2

1.3 Maksud dan Tujuan ... 2

1.4 Batasan Masalah ... 2

1.5 Metodologi Penelitian... 3

1.5.1 Tahap Pengumpulan Data ... 3

1.5.2 Tahap Pembangunan Perangkat Lunak ... 3

1.6 Sistematika Penulisan ... 5

BAB II LANDASAN TEORI ... 7

2.1 Logika Fuzzy ... 7

2.1.1 Alasan digunakannya Logika Fuzzy... 7

2.1.2 Variabel dan Himpunan Fuzzy ... 8

2.1.3 Fungsi Keanggotaan ... 9

2.1.4 Fuzzy Inference System... ...10

2.1.5 Model Defuzzifikasi Metode SUGENO ... 12

2.2 Game ... 13

2.2.1 Klasifikasi Game ... 14

vi

2.2.3 Berdasarkan Genre Permainan ... 16

2.2.4 OOP (Object Oriented Programming) ... 17

2.2.5 Konsep Dasar Berorientasi Objek ... 19

2.2.6 Analisis Berorientasi Objek ... 22

2.3 UML (Unified Modelling Language) ... 23

2.3.1 Diagram UML ... 24

2.3.2 Use Case Diagram... 25

2.3.3 Activity Diagram... 26

2.3.4 Sequence Diagram ... 26

2.3.5 Class Diagram ... 27

2.4 Tools yang digunakan ... 27

BAB III ANALISIS DAN KEBUTUHAN ALGORITMA ... 31

3.1 Analisis Masalah... 31

3.2 Analisis Game... 31

3.2.1 Skenario Game ... 32

3.2.2 Tahap Permainan ... 32

3.3 Analisis Masukan ... 34

3.3.1 Analisis Scoring ... 36

3.4 Analisis Algoritma Logika Fuzzy... 36

3.5 Analisis Kebutuhan Perangkat Lunak ... 39

3.5.1 Analisis Pengguna ... 41

3.5.2 Analisis Kebutuhan Fungsional ... 42

3.5.3 Use Case Diagram... 42

3.5.4 Definisi Aktor ... 43

3.5.5 Definisi Use case ... 44

3.5.6 Skenario Use case ... 45

3.5.7 Activity Diagram... 52

3.5.8 Sequence Diagram ... 61

3.5.9 Class Diagram ... 68

BAB IV IMPLEMENTASI DAN PENGUJIAN ... 69

vii

4.1.1 Implementasi Perangkat Keras ... 69

4.1.2 Implementasi Perangkat Lunak ... 70

4.1.3 Implementasi Antarmuka ... 70

4.1.4 Pengujian Simulasi ... 72

4.1.5 Pengujian Perilaku NPC Karakter Utama ... 72

4.1.6 Kesimpulan Pengujian ... 80

BAB V SARAN DAN KESIMPULAN ... 81

5.1 Kesimpulan ... 81

5.2 Saran ... 81

82

Gomes, Mario Rui. (2000). Modelling Reality With Simulation Games for a Cooperative Learning. Proceedings of the 2000 Winter Simulation Conference.

[2] Juliastika. (2012). Game Programming. Jurnal Design game dan level.1-5. [3] Setya Winarno, (2011), House Seismic Vulnerability and Mitigation Strategies: Case of Yogyakarta City, Jurnal Penanggulangan Bencana Volume 2 Nomor 2, Tahun 2011.

[4] Nasution Helfi. Program Studi Teknik Informatika Jurusan Teknik Elektro Fakultas Teknik Universitas Tanjungpura Pontianak. Implementasi Logika Fuzzy pada Sistem Kecerdasan Buatan. Pontianak.

[5] Widinugroho Dani. Hariadi Moch. Teknik Elektro ITS, Surabaya. RANCANG BANGUN RESPON DUA AGEN OTONOM DALAM AUGMENTED REALITY MENGGUNAKAN METODE LOGIKA FUZZY. 2011 Surabaya.

[6] ACF Pengalaman Respon Banjir , Jakarta, 30 November 2009.

[7] Prof (R). Drs. Erman Mawardi, Dipl.AIT. Asep Sulaeman, ST

“PARTISIPASI MASYARAKAT DALAM PENGURANGAN RESIKO

BENCANA BANJIR” Jakarta, Desember 2011.

[8] Tim Kajian Yayasaan Pengabdi Masyarakat. PENELITIAN DASAR DAN PERSIAPAN UNTUK SUB PROYEK SISTEM PERINGATAN DINI DAN EVAKUASI DINI DI KABUPATEN JEMBER. Evaluasi Simulasi Banjir Bandang di Desa Pace Kecamatan Silo 2010.

[9] Mislan. Pengajar Hidrologi-Jurusan Fisika FMIPA Universitas Mulawarman. BENCANA BANJIR, PENGENALAN KARAKTERISTIK

DAN KEBIJAKAN PENANGGULANGANNYA DI PROVINSI KALIMANTAN TIMUR. April 2011.

[10] Brookings-Bern Project on Internal Displacement 1775 Massachusetts Avenue, NW. MELINDUNGI PARA KORBAN BENCANA ALAM. Washington, DC. Juni 2006.

[11] Pablo Moreno-Ger a,*, Daniel Burgos b, Iván Martínez-Ortiz a, José Luis Sierra a, Baltasar Fernández-Manjón a. Spain. Educational game design for online education. Computers in Human Behavior (2008).

[12] Kusumadewi Sri. Purnomo Hari. APLIKASI LOGIKA FUZZY untuk pendukung keputusan – edisi ke dua – Yogyakarta; Graha Ilmu. 2013. [13] Pirovano Michele. The Use of Fuzzy Logic for Artificial Intelligence in

games. Department of Computer Science, University of Milano, Milano, Italy. Desember 2012.

[14] Hamam Abdelwahab, Mohamad Eid, Abdulmotaleb El Saddik, Nicolas D. Georganas. A Fuzzy Logic System for Evaluating Quality of Experience of Haptic-Based Applications. Laboratory University of Ottawa, Canada. [15] Permadi Yogi. GAME EDUKASI MENGENAL DAN MENYUSUN

HURUF ALPHABET. Universitas Komputer Indonesia. Bandung 2011. [16] Abdul Aziz Hamzah. MAKING APPLICATION USING BLENDER

GAME BOUNCE VERSION 2.49A. Perpustakaan Universitas Gunadarma . 2005.

[17] Kusna Ra’uf Uzi. PEMBUATAN GAME MATCH 10 MENGGUNAKAN ADOBE FLASH. YOGYAKARTA 2013.

[18] Fibrianto Rizqi Ahmad. Kecerdasan Buatan Pada Automation Bot Multiplayer Game dengan Finite-State Machine dan Fuzzy Logic. Bandung 2014.

[19] Hanks Brad. Unified Modeling Language (UML). South Jordan 2014

[20] Creighton Ryan Henson. Unity 3D Game Development by Example. 2008

[21] Ziqqi Alfiam Moch. PERANCANGAN SISTEM LINGKUNGAN UNTUK SIMULASI KEBAKARAN MENGGUNAKAN VISUALISASI 3D. Politeknik Elektronika Negeri Surabaya. Surabaya 2002.

[22] Eko Setianto Sigit. PENGENALAN ADOBE PHOTOSHOP CS. Jakarta 2006.

[23] Proboyekti Umi. SOFTWARE PROCESS MODEL ING. Jakarta 1997.

[24] Metodologi berorientasi obyek. PENGANTAR MODOLOGI BERORIENTASI OBJEK. Jakarta 2014

iii

KATA PENGANTAR

Assalamualaikum Wr.Wb.

Puji syukur penulis panjatkan kehadirat Allah SWT yang telah memberikan kekuatan, petunjuk, rahmat serta segala karuniaNya kepada penulis untuk dapat menyelesaikan skripsi ini dengan judul ”IMPLEMENTASI ALGORITMA FUZZY LOGIC PADA TINGKAT KESULITAN PERMAINAN EVAKUASI KORBAN BANJIR”.

Karya ilmiah ini disusun sebagai salah satu syarat kelulusan mata kuliah Tugas Akhir pada Program Strata Satu (S1) Jurusan Teknik Informatika. Telah banyak pihak yang membantu dalam penyusunan skripsi ini, baik secara moril maupun materil. Oleh karena itu, pada kesempatan ini penulis ingin menyampaikan ucapan dan rasa terima kasih yang sebesar-besarnya kepada : 1. Ayah, Ibu, Ade Nindy, Dede Lia, Mamah, Papah, serta Momy Fanny yang

selalu memberikan semangat, dorongan motivasi, kasih sayang serta doa yang tidak henti-hentinya yang selalu menyertai penulis.

2. Ibu Nelly Indriani W, S.Si., M.T. selaku Dosen Pembimbing yang senantiasa memberikan bimbingan, ilmu, saran dan waktu luangnya sehingga penulis dapat menyelesaikan karya ilmiah tugas akhir ini.

3. Ibu Ednawati Rainarli, S.Si., M.Si. selaku Dosen Reviwer terima kasih atas semua masukannya.

4. Teman-teman mahasiswa yang telah memberikan dukungan dan bantuan selama masa perkuliahan berlangsung yang tidak bisa penulis sebutkan namanya satu-persatu.

Dan semua pihak yang membantu penulis baik langsung maupun tidak langsung, semoga Allah SWT membalasnya. Akhir kata sebagai makhluk Tuhan penulis menyadari pasti ada kekurangan dan kelemahan yang terdapat pada karya ilmiah skripsi ini.

iv

Untuk itu penulis mengharapkan adanya masukan berupa kritik dan saran dari semua pihak. Semoga karya ilmiah ini bermanfaat dan kita tidak akan pernah berhenti untuk menuntut ilmu sepanjang hidup kita. Amin.

Wassalamualaikum Wr. Wb.

Bandung, Agustus 2014

1 1.1 Latar Belakang Masalah

Game umumnya terdapat sebuah tingkat kesulitan, dimulai dari tingkat kesulitan yang berawal dari tingkat kesulitan mudah (easy), sedang (medium), hingga sulit (hard). Perubahan tingkat kesulitan ditandai dengan adanya penambahan level didalam game. Semakin bertambahnya level didalam game, maka tingkat kesulitan akan bertambah pula. Namun didalam perkembangan game, tidak selalu perubahan tingkat kesulitan berubah seiring dengan pertambahan level. Terdapat juga game yang dalam satu level namun mengalami perubahan tingkat kesulitan. Salah satunya adalah game snakes.

Game snakes adalah game yang tidak memiliki tahapan level. Namun tingkat kesulitan bermula dari tingkat termudah hingga tingkat yang tersulit. Dalam game snakes cenderung setelah tingkat kesulitan berada pada tahap sulit, maka game snakes akan terus berada pada tahap tersebut. Maka dari pernyataan itu pemain tidak mengalami perubahan level saat pemain terus berada pada level tersebut. Dalam perkembangan game juga dibutuhkan pengaturan tingkat kesulitan yang berubah-ubah dalam satu level, sehingga dalam permainan tidak terasa membosankan karena permainan tidak mudah ditebak.

Dari hasil pemaparan tersebut, maka diperlukan pengimplementasian logika fuzzy pada tingkat kesulitan game evakuasi korban banjir. Logika Fuzzy itu sendiri merupakan suatu logika yang memiliki nilai kekaburan atau kesamaran (fuzzyness) antara benar atau salah. Dalam teori logika fuzzy suatu nilai bisa bernilai benar atau salah secara bersama. Namun berapa besar keberadaan dan kesalahan suatu tergantung pada bobot keanggotaan yang dimilikinya[4]. Dalam penerapannya logika fuzzy merupakan suatu cara untuk memetakan permasalahan dari Input menuju output yang diharapkan terutama dalam sistem pengambilan keputusan. logika fuzzy sendiri mampu beradaptasi dengan perubahan-perubahan, dan ketidakpastian yang menyertai permasalahan.

Berdasarkan permasalahan yang telah dijelaskan, maka akan diimplementasikannya algoritma logika fuzzy pada tingkat kesulitan game evakuasi korban banjir yang dimana tingkat kesulitan berada dalam satu level dengan tingkat kesulitan yang mampu berubah saat tingkat kesulitan berada pada tingkat tersulit.

1.2 Rumusan Masalah

Berdasarkan latar belakang yang telah diuraikan sebelumnya, maka masalah yang akan di kaji pada tugas akhir ini adalah. Bagaimana mengimplementasi algoritma logika fuzzy pada tingkat kesulitan permainan evakuasi korban banjir ?

1.3 Maksud dan Tujuan

Berdasarkan permasalahan yang diteliti, maka maksud dari penulisan tugas akhir ini adalah mengimplementasikan algoritmana logika fuzzy pada aplikasi game tingkat kesulitan evakuasi korban banjir. Sedangkan tujuan yang akan dicapai dalam penelitian ini adalah :

1. Memberikan gambaran perubahan kondisi yang harus dihadapi pemain dalam game yang sesuai dengan rule yang telah ditentukan.

2. Tingkat kesulitan game yang tidak terjadi secara berurutan.

1.4 Batasan Masalah

Dalam penelitian ini, ada beberapa batasan masalah yaitu sebagai berikut:

1. Game yang dibangun berupa game dengan tampilan 2D.

2. Game yang dibangun berupa simulasi.

3. Kecerdasan buatan yang digunakan adalah algoritma logika fuzzy dengan metode Sugeno.

4. Jumlah Input pada game terdapat 2 kondisi, sedangkan untuk output terdapat 3 kondisi.

1.5 Metodologi Penelitian

Metodologi penelitian yang akan digunakan dalam pembuatan tugas akhir ini adalah metode penelitian deskriptif yaitu metode yang menggambarkan secara sistematika dan akurat mengenai keadaan-keadaan nyata yang berjalan pada saat penelitian. Metodologi penelitian pada penelitian tugas akhir ini dibagi menjadi dua proses yaitu :

1.5.1 Tahap pengumpulan data

Metode pengumpulan data yang digunakan dalam penelitian ini adalah sebagai berikut :

a. Studi Literatur.

Pengumpulan data dengan cara mengumpulkan literatur, jurnal, paper dan bacaan-bacaan yang ada kaitannya dengan judul penelitian.

b. Analisis

Analisis dilakukan dengan menentukan struktur data , Input/output serta algoritma yang akan digunakan.

c. Pengujian

Pengujian dilakukan dengan menerapkan algoritma logika fuzzy pada kecerdasan buatan game penentuan tingkat kesulitan game evakuasi korban banjir..

1.5.2 Tahap pengembangan perangkat lunak

Metode pembangunan perangkat lunak menggunakan model protoType. Alasan menggunakan metode protoType adalah karena metode ini melakukan pengumpulan kebutuhan dan memperbaiki kebutuhan, melakukan desain dengan cepat dan mengevaluasi kebutuhan oleh pemakai agar sesuai dengan kebutuhan. Pada Gambar 1.1 menunjukan tahapan-tahapan model protoType yaitu sebagai berikut :

1. Requirement Gathering and Refinement (Pengumpulan Kebutuhan dan

Mengumpulkan kebutuhan untuk merancang sebuah game dan juga melakukan perbaikan game jika terdapat kekurangan.

2. Quick Desain (Desain Cepat)

Mendesain secara cepat aplikasi game sesuai dengan kebutuhan pemakai. 3. Building ProtoType (Bentuk ProtoType)

Aplikasi game yang sudah didesain akan dirancang ke dalam bahasa pemrograman dengan menggunakan tools yang ada.

4. Customer Evalution of ProtoType (Evaluasi Pemakai Terhadap ProtoType)

Setelah game sudah jadi, selanjutnya game ini diuji dengan memasukan algoritma yang akan dipakai. Setelah diuji, kemudian diberikan kepada pemakai agar dapat mengetahui game yang sudah diuji.

5. Refining ProtoType (Perbaikan ProtoType)

Memperbaiki game yang sudah jadi dengan menguji kembali algoritma pada game ataupun yang tidak sesuai dengan kebutuhan pemakai. Setelah game sudah diperbaiki, kemudian dapat diberikan kembali kepada pemakai agar dapat mengetahui game yang sudah diuji.

6. Engineer Product (Produk Rekayasa)

Aplikasi game sudah sesuai dengan kebutuhan pemakai.

1.6 Sistematika Penulisan

Sistematika penulisan penelitian ini disusun untuk memberikan gambaran umum tentang penelitian yang dijalankan. Sistematika penulisan tugas akhir ini adalah sebagai berikut :

BAB I PENDAHULUAN

Pada bab ini berisi latar belakang masalah, identifikasi masalah, maksud dan tujuan, metodologi penelitian, batasan masalah, sistematika penulisan, jadwal kegiatan, gambaran sistem dan daftar pustaka.

BAB II. LANDASAN TEORI

Membahas berbagai konsep dasar dan teori tentang algoritma logika fuzzy, pengertian banjir, pengertian game, klasifikasi game, game edukasi, jenis-jenis game, genre game, unsur game, elemen dasar game, konsep dasar berorientasi objek, analisis berorientasi objek, desain berorientasi objek , pemodelan , UML, Diagram UML, Javascript, Pengujian Perangkat Lunak, Unity, dan Adobe Photoshop.

BAB III. ANALISIS DAN KEBUTUHAN ALGORITMA

Merupakan tahapan Menganalisis masalah, analisis game, skenario game , jenis permainan, analisis masukan, analisis scoring , analisis algoritma logika fuzzy, alanisis kebutuhan perangkat lunak , analisis pengguna , dan analisis kebutuhan fungsional yang berisi usecase diagram, skenario usecase , Activity Diagram , sequen diagram dan class diagram . Pada penerapan game simulasi korban banjir dengan Input cuaca dan kuota korban. Sedangkan untuk output tingkat kesulitan yaitu mudah , sedang , dan sulit.

BAB IV. IMPLEMENTASI DAN PENGUJIAN

Merupakan tahapan yang dilakukan dalam penelitian secara garis besar sejak dari tahap persiapan sampai penarikan kesimpulan, metode dan kaidah yang diterapkan dalam penelitian. Termasuk menentukan variabel penelitian, identifikasi data yang diperlukan dan cara pengumpulannya, penentuan sampel

penelitian dan teknik pengambilannya, serta metode/teknik analisis yang akan dipergunakan dan perangkat lunak yang akan dibangun jika ada.

BAB V. KESIMPULAN DAN SARAN

Pada bab ini berisi tentang kesimpulan yang diperoleh dari hasil penulisan tugas akhir dan saran untuk perbaikan hasil dari penelitian.

7

2.1 Logika Fuzzy

Konsep tentang logika fuzzy diperkenalkan oleh Prof. Lotfi Astor Zadeh pada 1962. Logika fuzzy adalah metodologi sistem kontrol pemecahan masalah yang cocok diimplementasikan pada sistem, mulai dari sistem yang sederhana, sistem kecil, embedded sistem, jaringan PC, multi-channel atau workstation berbasis akurasi data, dan sistem kontrol. Metodologi ini dapat diterapkan pada perangkat keras, perangkat lunak, atau kombinasi keduanya. Dalam logika klasik dinyatakan bahwa segala sesuatu bersifat biner, yang artinya adalah hanya mempunyai dua kemungkinan, “Ya atau Tidak”, “Benar atau Salah”, “Baik atau Buruk” dan lain-lain. Oleh karena itu, semua ini dapat mempunyai nilai keanggotaan 0 dan 1. Akan tetapi, dalam logika fuzzy memungkinakan nilai keanggotaan berada diantara 0 dan 1. Artinya, bisa saja suatu keadaan mempunyai dua nilai “Ya dan Tidak”, “Benar dan Salah”, “Baik dan Buruk” secara bersamaan, namun besar nilainya tergantung pada bobot keanggotaan yang dimilikinya. Logika fuzzy dapat digunakan diberbagai bidang, seperti pada sistem diagnosis penyakit (dalam bidang kedokteran), pemodelan sistem pemasaran, riset operasi (dalam bidang ekonomi), kendali kualitas air, prediksi adanya gempa bumi, klasifikasi dan pencocokan pola (dalam bidang teknik)[20].

2.1.1 Alasan digunakannya Logika Fuzzy

Menurut Cox (1994) , ada beberapa alasan mengapa orang menggunakan logika fuzzy adalah Konsep logika fuzzy mudah dimengerti , karena fuzzy menggunakan dasar teori himpunan , maka konsep matematis yang mendasari penaralan fuzzy tersebut cukup mudah untuk dimengerti dan logika fuzzy sangat fleksibel, artinya mampu beradaptasi dengan perubahan-perubahan dan ketidakpastian yang menyertai permasalahan.

2.1.2 Variabel dan Himpunan Fuzzy

Dalam ilmu logika fuzzy dikenal mengenal dua himpunan, yaitu himpunan crisp (tegas) dan himpunan fuzzy (samar).

Himpunan crisp adalah himpunan yang menyatakan suatu obyek merupakan anggota dari satu himpunan memiliki nilai keanggotaan (µ) = ya (1) atau tidak (0), oleh karena itu himpunan crisp disebut himpunan tegas.

Misalkan variabel umur dibagi 3 kategori, yaitu: MUDA < 35 tahun ; PAROBAYA 35 ˄ umur ˄ 55 tahun ; TUA > 55 tahun. yang dapat di lihat pada gambar 2.1:

Gambar 2.2 Himpunan crisp

Jika menggunakan himpunan crisp, dapat diambil kesimpulan bahwa: 2. Usia 34 tahun, dikatakan MUDA → µMUDA[34]=1

3. Usia 35 tahun kurang 1 hari, dikatakan MUDA → µMUDA[35th-1hr]=1 4. Usia 35 tahun, dikatakan TIDAK MUDA → µMUDA[35]=0

5. Usia 55 tahun, dikatakan PAROBAYA → µPAROBAYA[55]=1

6. Usia 55 tahun lebih 1 hari, dikatakan TIDAK PAROBAYA → µPAROBAYA[55th+1hr]=0 atau

7. Usia 55 tahun lebih 1 hari, dikatakan TUA → µTUA[55th+1hr]=1

Dari kesimpulan diatas, himpunan crisp menyatakan umur seseorang kedalam suatu kategori secara tidak adil, karena orang yang berusia 35 tahun dikatakan parobaya, sedangkan orang yang berusia 35 tahun kurang 1 hari

dikatakan tidak parobaya (karena masuk kategori muda). selisih 1 hari saja menimbulkan berbedaan kategori yang signifikan.

Sedangkan untuk himpunan fuzzy adalah himpunan yang menyatakan suatu obyek dapat menjadi anggota dari beberapa himpunan dengan nilai keanggotaan (µ) yang berbeda. Untuk lebih jelasnya , perhatikan contoh dibawah:

Himpunan Fuzzy digunakan untuk mengatasi hal tersebut, sehingga dengan menggunakan himpunan fuzzy, seseorang dapat masuk ke dua kategori secara bersamaan, misalnya seseorang yang berusia 35 tahun kurang 1 hari dapat masuk kategori MUDA dan PAROBAYA sekaligus. Lihat gambar 2.3 :

Gambar 2.3 Himpunan Fuzzy contoh:

1. Seseorang yang berumur 40 tahun termasuk dalam himpunan MUDA dengan µMUDA[40]=0,25; namun dia juga termasuk dalam himpunan PAROBAYA dengan µPAROBAYA[40]=0,5.

2. Seseorang yang berumur 50 tahun termasuk dalam himpunan MUDA dengan µMUDA[50]=0,25; namun dia juga termasuk dalam himpunan PAROBAYA dengan µPAROBAYA[50]=0,5 [20]

2.1.3 Fungsi Keanggotaan

Fungsi keanggotaan adalah suatu kurva yang menunjukan pemetaan titik-titik Input data ke dalam nilai keanggotaan (sering juga disebut dengan derajat keanggotaan) yang memiliki interval antara 0 sampai 1. Salah satu cara yang

dapat digunakan untuk mendapatkan nilai keanggotaan adalah dengan menggunakan pendekatan fungsi. Salah satunya representasi kurva trapesium. Representasi kurva trapesium pada dasarnya berbentuk segitiga trapesium. Pada kurva ini memiliki nilai keanggotaan 1 (gambar 2.3).

Gambar 2.4 Representasi Kurva Trapesium Fungsi Keanggotaan :

(2.1)

Keterangan:

a = nilai domain terkecil yang mempunyai derajat keanggotaan nol b = nilai domain terkecil yang mempunyai derajat keanggotaan satu c = nilai domain terbesar yang mempunyai derajat keanggotaan satu d = nilai domain terbesar yang mempunyai derajat keanggotaan nol x = nilai Input yang akan di ubah ke dalam bilangan fuzzy

2.1.4 FuzzyInference System

Pada Fuzzy Inference System, terdapat 3 metode, yaitu metode tsukamoto, mamdani dan sugeno.

1. Pada metode Tsukamoto , setiap konsekuen pada aturan yang berbentuk IF-Then harus direpresentasikan dengan suatu himpunan fuzzy dengan fungsi keanggotaan yang monoton. Sebagai hasilnya, output hasil inferensi dari tiap-tiap aturan diberikan secara tegas (crisp) berdasarkan α-predikat (fire strength). Hasil akhirnya diperoleh dengan menggunakan rata-rata terbobot[20].

2. Metode Mamdani sering disebut metode Max-Min. Metode ini diperkenalkan oleh Ebrahim Mamdani pada tahun 1975. Untuk mendapatkan output diperlukan 4 tahapan yaitu tahapan pembentukan himpunan fuzzy, aplikasi fungsi implikasi, komposisi aturan, dan penegasan(defuzzy).

3. Penalaran dengan metode Sugeno hampir sama dengan penalaran metode Mamdani , hanya saja output (konsekuen) sistem tidak berupa himpunan fuzzy, melainkan berupa konstanta atau persamaan linear. Metode ini diperkenalkan oleh Takagi-Sugeno Kang pada tahun 1985, sehingga metode ini sering juga dinamakan metode TSK. Apabila komposisi aturan menggunakan metode Sugeno, maka defuzzyfikasi dilakukan dengan cara mencari nilai rata-ratanya.

Cara kerja logika fuzzy dapat digambarkan sebagai struktur elemen dasar sistem inferensi fuzzy pada gambar 2.4:

Keterangan :

1. Basis Pengetahuan Fuzzy merupakan kumpulan rule-rule fuzzy dalam bentuk pernyataan IF…THEN.

2. Fuzzyfikasi adalah proses untuk mengubah Input sistem yang mempunyai nilai tegas menjadi variabel linguistic menggunakan fungsi keanggotaan yang disimpan dalam basis pengetahuan fuzzy.

3. Mesin Inferensi merupakan proses untuk mengubah Input fuzzy dengan cara mengikuti aturan-aturan (IF-THEN Rules) yang telah ditetapkan pada basis pengetahuan fuzzy.

4. Defuzzyfikasi merupakan proses mengubah output fuzzy yang diperoleh dari mesin inferensi menjadi nilai tegas menggunakan fungsi keanggotaan yang sesuai dengan saat dilakukan fuzzyfikasi

2.1.5 Model Defuzzifikasi Metode SUGENO

Langkah-langkah dalam penentuan defuzzifikasi menggunakan metode Sugeno dilakukan dengan cara sebagai berikut:

1. Menggunakan aturan Conjunction ( ) dengan memilih derajat keanggotaan minimum pada perhitungan kasus yang ada.

2. Setelah aturan Conjunction selesai, lanjut pada Aturan Disjunction ( ) dimana memilih derajat keangotaan maksimum dari hasil aturan Conjunction.

3. Setelah aturan Conjunction dan Disjunction selesai, dibuatlah grafik derajat keanggotaan model sugeno.

Gambar 2.6 Grafik derajat keanggotaan model sugeno

20 40 0 1 Aturan1 Aturan3 µ Aturan2 60

Keterangan :

1. Aturan1, Aturan2, Aturan3 = merupakan hasil output yang dihasilkan dari sistem fuzzy

2. 0-20 = nilai (range) yang ada pada hasil output Aturan1 3. 20-40 = nilai (range) yang ada pada hasil output Aturan2 4. 40-60 = nilai (range) yang ada pada hasil output Aturan3

4. Kemudian mencari rata-rata perhitungan menggunakan rumus (weight average Method)[12]:

a. Rumus Weighted Average Method

(2.1)

Keterangan:

2.2 Game

Game merupakan kata dalam bahasa inggris yang berarti permainan. Permainan adalah sesuatu yang dapat dimainkan dengan aturan tertentu sehingga ada yang menang dan ada yang kalah, biasanya dalam konteks tidak ada serius atau dengan tujuan refreshing. Suatu cara belajar yang digunakan dalam menganalisa interaksi antara sejumlah pemain maupun perorangan yang menunjukan strategi-strategi yang rasional. Teori permainan pertama kali ditemukan oleh sekelompok ahli Matematika pada tahun 1944. Teori itu dikemukakan oleh John Von Neumann dan Oskar Morgenstern yang berisi: “Permainan terdiri atas sekumpulan peraturan yang membangun situasi bersaing dari dua sampai beberapa orang atau kelompok dengan memilih strategi yang dibangun untuk memaksimalkan kemenangan sendiri atau pun untuk meminimalkan kemenangan lawan. Peraturan-peraturan menentukan kemungkinan tindakan untuk setiap pemain, sejumlah keterangan diterima setiap

pemain sebagai kemajuan bermain, dan sejumlah kemenangan atau kekalahan dalam berbagai situasi” [18]. Pengertian game menurut para ahli :

1. Menurut Agustinus Nilwan dalam bukunya Pemograman Animasi dan

Game Profesional terbitan Media Komputindo, game merupakan

permainan komputer yang dibuat dengan teknik dan metode animasi. Jika ingin mendalami penggunaan animasi haruslah memahami pembuatan game. Atau jika ingin membuat game, maka haruslah memahami teknik dan metode animasi, sebab keduanya saling berkaitan.

2. Menurut Clark C. Abt, Game adalah kegiatan yang melibatkan keputusan pemain, berupaya mencapai tujuan dengan dibatasi oleh konteks tertentu (misalnya, dibatasi oleh peraturan).

3. Menurut Chris Crawford, seorang computer game designer mengemukakan bahwa game, pada intinya adalah sebuah interaktif. Aktivitas yang berpusat pada sebuah pencapaian, ada pelaku aktif (player), ada pelaku pasif (NPC).

4. Menurut David Parlett, game adalah sesuatu yang memiliki “akhir dan cara mencapainya” : artinya ada tujuan, hasil dan serangkaian peraturan untuk mencapai keduanya.

5. Menurut Roger Caillois, seorang sesiolog Perancis dalam bukunya yang berjudul Les Jeux Et Les Hommes menyatakan game adalah aktivitas yang mencakup karakteristik berikut: fun (bebas bermain adalah pilihan bukan kewajiban), separate (terpisah), uncertain, non-productive, governed by rules (ada aturan), fictitious (pura-pura).

6. Menurut Greg Costikyan, game adalah “sebentuk karya seni dimana peserta, yang disebut pemain, membuat keputusan untuk mengelola sumber daya yang dimilikinya melalui benda di dalam game demi mencapai tujuan”.

2.2.1 Klasifikasi Game

Game biasanya digunakan untuk mengkatagorikan sebuah game

Sebuah jenis game dapat didefinisikan dengan kumpulan dari sebuah tipe permainan dari game tersebut. Game dapat diklasifikasikan menjadi dua, yaitu[2]:

2.2.2 Berdasarkan Jenis Platform yang Digunakan

Tiga kategori utama platform pada game adalah personal computer (PC), console, dan mobile[2]:

1. Personal Computer (PC)

PC game adalah game yang dibuat untuk computer baik berbasis

Windows, Mac, ataupun Linux. PC menyediakan kekuatan grafis dan pemrosesan yang kuat yang memungkinkan pengembang untuk membuat game yang mutakhir. Tetapi kelemahan game PC adalah mahal karena pengguna harus menggunakan hardware yang up-to-date untuk memainkan game PC dengan baik. Selain itu, kelemahan game PC bagi pengembang adalah banyaknya varian dari konfigurasi PC membuat sulit bagi pengembang untuk memastikan game tersebut berjalan dengan benar pada semua setup PC.

2. Console

Console adalah hardware yang dibuat oleh pihak ketiga seperti Sony, Microsoft, dan Nintendo. Console terhubung ke televisi dan tujuan utamanya adalah untuk bermain game. Game Console sangat menarik bagi game pengembang karena mereka hanya perlu memikirkan satu konfigurasi hardware ketika membuat software untuk console. Sangat kontras dengan PC yang memiliki opsi konfigurasi yang tak terbatas.

3. Mobile

Mobile platform terdiri atas sesuatu yang portable dan bisa digenggam, termasuk ponsel, PDA, iPods, dan handheld game seperti Nintendo DSi atau Sony PSP. Game mobile memiliki kontrol yang sederhana (terutama jika dibandingkan dengan PC).

2.2.3 Berdasarkan Genre Permainan

Genre game bisa dibagi menjadi 9 genre, yang dimana tiap genre memiliki karakteristik tersendiri , yaitu[2]:

1. Action

Action game adalah game dimana kebanyakan dari tantangan yang

disajikan merupakan dari tes physical skill dan koordinasi pemain. Salah satu sub-genre action game adalah shooters game, baik yang 2D maupun 3D seperti First Person, Shooters (FPS).

2. Strategy

Strategy game menantang pemain untuk mencapai kemenangan dengan perencanaan, khususnya melalui perencanaan serangkaian tindakan yang dilakukan melawan satu lawan atau lebih. Kemenangan diraih dengan perencanaan matang dan pengambilan keputusan yang optimal.

3. Role Playing Game (RPG)

RPG adalah game dimana pemain mengontrol satu atau lebih karakter yang biasanya di desain oleh pemain itu sendiri, dan memandu mereka melewati berbagai rintangan yang diatur oleh komputer.Perkembangan karakter dalam hal kekuatan dan kemampuannya adalah kunci dari game jenis ini.

4. Sports

Sports game mensimulasikan berbagai aspek dari olahraga atletik nyata maupun imajiner, apakah itu memainkan pertandingan, me-manage tim dan karir, atau keduanya. Salah satu contoh game jenis ini adalah Pro Evolution Soccer 2012 (PES 2012), dimana pemain bisa memainkan pertandingan, menjadi manajer tim, maupun menjadi pemain dan mengembangkan karirnya sendiri.

5. Vechicle Simulation

Vechicle simulation membuat feeling mengendarai kendaraan, baik kendaraan nyata maupun kendaraan imajiner. Performa dan karakteristik

kasar mesin harus menyerupai kenyataan, kecuali jika yang didesain adalah kendaraan imajiner.

6. Construction and Management Simulation

CMS game adalah game tentang proses. Tujuan pemain bukan untuk mengalahkan musuh, tetapi membangun sesuatu dengan konteks proses yang sedang berjalan. Semakin pemain mengerti dan mengontrol proses, semakin sukses sesuatu yang ia bangun. Game seperti ini biasanya menyediakan dua jenis permainan, yaitu mode bebas dimana pemain bebas membangun sesuatu, dan mode misi dimana terdapat skenario hal apa yang harus dibangun oleh pemain.

7. Adventure

Adventure game adalah cerita interaktif tentang karakter protagonist yang dimainkan oleh pemain. Penyampaian cerita dan eksplorasi adalah elemen inti dari game ini. Penyelesaian teka-teki dan tantangan konseptual adalah bagian besar dari permainan.

8. Artificial Life and Puzzle Game

Artificial Life game adalah game yang membuat tiruan dari kehidupan sebenarnya. Biasanya ada dua jenis game ini, tiruan kehidupan manusia, contohnya The SIMS, dan tiruan kehidupan binatang, contohnya Tamagochi.

9. Online Game

Istilah online game disini mengacu kepada multiplayer game dimana mesin dari para pemain terhubung dengan jaringan.

2.2.4 OOP (Object Oriented Programming)

Metodologi berorientasi objek adalah suatu strategi pembangunan perangkat lunak yang mengorganisasikan perangkat lunak sebagai kumpulan objek yang berisi data dan operasi yang diberlakukan terhadapnya. Metodologi berorientasi objek merupakan suatu cara bagaimana sistem perangkat lunak dibangun melalui pendekatan objek secara sistematis. Metode berorientasi objek didasarkan pada penerapan prinsip-prinsip pengelolaan kompleksitas. Metode

berorientasi onjek meliputi rangkaian aktivitas analisis berorientasi objek, perancangan berorientasi objek, pemrograman berorientasi objek, dan pengujian berorientasi objek.

Pada saat ini, metode berorientasi objek banyak dipilih karena metodologi lama banyak menimbulkan masalah seperti adanya kesulitan pada saat mentransformasi hasil dari satu tahap pengembangan ke tahap berikutnya, misalnya pada metode pendekatan terstruktur, jenis aplikasi yang dikembangkan saat ini berbeda dengan masa lalu. Aplikasi yang dikembangkan saat ini sangat beragam (aplikasi bisnis, real-time, utility, dan sebagainya) dengan platform yang berbeda-beda, sehingga menimbulkan tuntutan kebutuhan metodologi pengembangan yang dapat mengakomodasi ke semua jenis aplikasi tersebut[24]. Keuntungan menggunakan metodologi berorientasi objek adalah sebagai berikut[24]:

a. Meningkatkan produktivitas

Karena kelas dan objek yang ditemukan dalam suatu masalahmasih dapat dipakai ulang untuk masalah lainnya yang melibatkan objek tersebut (reusable).

b. Kecepatan pengembangan

Karena sistem yang dibangun dengan baik dan benar pada saat analisis dan perancangan akan menyebabkan berkurangnya kesalahan pada saat pengkodean.

c. Kemudahan pemeliharaan

Karena dengan model objek, pola-pola yang cenderung tetap dan stabil dapat dipisahkan dan pola-pola yang mungkin sering diubah-ubah.

d. Adanya konsistensi

Karena sifat pewarisan dan penggunaan notasi yang sama pada saat analisis, perancangan maupun pengkodean.

e. Meningkatkan kualitas perangkat lunak

Karena adanya pendekatan pengembangan lebih dekat dengan dunia nyata dan adanya konsistensi pada saat pengambangannya, perangkat lunak yang

dihasilkan akan mampu memenuhi kebutuhan pemakai serta mempunyai sedikit kesalahan.

Berikut beberapa contoh bahasa pemrograman yang mendukung pemrograman berorientasi objek[24] :

a. Smalltalk

Smalltalk merupakan salah satu bahasa pemrogramanyang dikembangkan untuk mendukung pemrograman berorientasi objek mulai tahun 1978. b. Bahasa Pemrograman Eiffel

Eiffel merupakan bahasa pemrograman yang dikembangkan untuk mendukung pemrograman berorientasi objek mulai tahun 1985 oleh Bertrand Meyer dan compiler Eiffel selesai pada tahun 1987.

c. Bahasa Pemrograman C++

C++ merupakan pengembangan lebih lanjut bahasa pemrograman C untuk mendukung pemrograman berorientasi objek.

d. Bahasa Pemrograman (web) PHP

PHP dibuat pertama kali oleh seorang perekayasa perangkat (software engineering) yang bernama Rasmus Lerdoff.

e. Bahasa Pemrograman Java

Java dikembangkan oleh perusahaan Sun Microsystem. Java menurut definisi dari Sun Microsystem adalah nama untuk sekumpulan teknologi untuk membuat dan menjalankan perangkat lunak pada komputer standalone ataupun pada lingkungan jaringan[24].

2.2.5 Konsep Dasar Berorientasi Objek

Pendekatan berorientasi objek merupakan suatu teknik atau cara pendekatan dalam melihat permasalahan dan sistem (sistem perangkat lunak, sistem informasi, atau sistem lainnya). Pendekatan berorientasi obejek akan memandang sistem yang akan dikembangkan sebagai suatu kumpulan objek yang berkorespondensi dengan objek-objek dunia nyata[24].

Berikut ini adalah beberapa konsep dasar yang harus dipahami tentang metodelogi berorientasi objek:

1. Kelas (class)

Kelas adalah kumpulan objek-objek dengan karakteristik yang sama. Kelas merupakan definisi statis dan himpunan objek yang sama yang mungkin lahir atau tercipta dan kelas tersebut. Sebuah kelas akan mempunyai sifat (atribut), kelakuan (operasi/metode), hubungan (relationship) dan arti. Suatu kelas dapat diturunkan dan kelas yang lain, dimana atribut dan kelas semula dapat diwariskan ke kelas yang baru.

2. Objek (object)

Objek adalah abstraksi dan sesuatu yang mewakilkan dunia nyata seperti benda, manusia, satuan organisasi, tempat, kejadian, struktur, status, atau hal-hal lain yang bersifat abstrak. Objek merupakan entitas yang mampu menyimpan informasi (status) dan mempunyai operasi (kelakuan) yang dapat diterapkan atau dapat berpengaruh pada status objeknya. Objek mempunyai siklus hidup yaitu diciptakan, dimanipulasi, dan dihancurkan.

3. Metode (method)

Operasi atau metode pada sebuah kelas hampir sama dengan fungsi prosedur pada metodelogi structural. Sebuah kelas boleh memiliki lebih dari satu metode atau operasi yang berfungi untuk memanipulasi objek itu sendiri. Operasi atau metode merupakan fungsi atau transformasi yang dapat dilakukan terhadap objek atau dilakukan oleh objek.

4. Atribut (attribute)

Atribut dari sebuah kelas adalah variable global yang dimiliki sebuah kelas. Atribut dapat berupa nilai atau elemen-elemen data yang dimiliki oleh objek dalam kelas objek. Atribut dipunyai secara individual oleh sebuah objek, misalnya berat, jenis, nama dan sebagainya.

Prinsip untuk merepresentasikan dunia nyata yang kompleks menjadi satu bentuk model yang sederhana dengan mengabaikan aspek-aspek lain yang tidak sesuai dengan permasalahan.

6. Enkapsulasi (encapsulation)

Pembungkusan atribut data dan layanan (operasi-operasi)yang dipunyai objek untuk menyembunyikan implementasi dan objek sehingga objek lain tidak mengetahui cara kerjanya.

7. Pewarisan (inheritance)

Mekanisme yang memungkinkan suatu objek mewarisi sebagian atau seluruh definisi dan objek lain sebagai bagian dari dirinya.

8. Antarmuka (Interface)

Antarmuka (Interface) sangat mirip dengan kelas, tapi tanpa atribut kelas dan memiliki metode yang dideklarasikan tanpa isi. Deklarasi metode pada sebuah interface dapat diimplementasikan oleh kelas lain.

9. Reusability

Pemanfaatan kembali objek yang sudah didefinisikan untuk suatu permasalah pada permasalahan lainnya yang melibatkan objek tersebut

10. Generalisasi dan Spesialisasi

Menunjukkan hubungan antara kelas dan objek yang umum dengan kelas dan objek yang khusus. Misalnya kelas yang lebih umum (generalisasi) adalah kendaraan darat dan kelas khususnya (spesialisasi) adalah mobil, motor, dan kereta.

11. Komunikasi Antar Objek

Komunikasi Antar Objek dilakukan lewat pesan (message) yang dikirim dari satu objek ke objek yang lain.

12. Polimorfisme (polymorphism)

Kemampuan suatu objek untuk digunakan di banyak tujuan yang berbeda dengan nama yang sama sehingga menghemat baris program.

13. Package

Package adalah sebuah container atau kemasan yang dapat digunakan untuk mengelompokkan kelas-kelas sehingga memungkinkan beberapa kelas yang bernama sama disimpan dalam package yang berbeda

2.2.6 Analisis Berorientasi Objek

Analisis berorientasi objek atau Object Oriented Analysis (OOA) adalah tahap untuk menganalisis spesifikasi atau kebutuhan akan sistem yang akan dibangun dengan konsep berorientasi objek, apakah benar kebutuhan yang ada dapat diimplementasikan menjadi sebuah sistem berorientasi objek. Pendekatan analisa berarah objek terdiri dari lima pokok aktivitas, yaitu[24]:

1. Menentukan Kelas dan Objek

Pengertian objek adalah suatu abstraksi dari suatu lingkup permasalahan / implementasi yang menggambarkan kemampuan dari sistem untuk menangkap informasi tentang objek tersebut, berinteraksi dengan atau keduanya; "pembung-kusan" pada nilai atribut dan service-nya. Kelas adalah suatu gambaran dari satu atau lebih objek, penggambaran dengan sekumpulan atribut dan service yang sama. Menggambarkan bagaimana untuk menciptakan objek-objek baru dalam suatu kelas.

2. Identifikasi Struktur

Struktur adalah suatu ekspresi dari lingkup permasalahan yang komplek, berhubungan dengan tanggungjawab terhadap sistem. Istilah struktur digunakan sebagai sebuah istilah yang menggambarkan struktur generalisasi-spesialisasi (gen-spec) dan struktur keseluruhan dan bagiannya (whole-part). 3. Identifikasi Subjek

Subjek adalah suatu mekanisme yang membantu pembaca untuk menganalisa model permasalahan dari yang kecil hingga ke yang besar dan komplek. Pada lapisan subjek, gambarkan setiap subjek sebagai kotak persegi yang sederhana, dengan nama subjek dan nomor didalamnya sebagai tambahan, daftarkan kelas-kelas yang termasuk didalam subjek tersebut. Pada lapisan

yang lain indikasikan subjek dengan label subjek pada sekat pemisah kotak subjek untuk memandu pembaca dari subjek ke subjek lainnya. Dalam model yang besar dan membutuhkan fasilitas komunikasi, pertimbangkan penggunaan "set" dari lapisan secara terpisah untuk setiap subjek. Sebuah kelas dari subjek berada didalam lebih dari satu subjek. Subjek boleh berisi subjek lainnya. Persiapkan pemetaan multi level untuk membantu pembaca dalam suatu model yang besar.

4. Pendefinisian Atribut

Atribut adalah beberapa data (state information) dimana setiap objek di dalam suatu kelas mempunyai nilai tersendiri.

5. Pendefinisian Service

Service adalah tingkah laku yang spesifik, yaitu tingkah laku yang memperlihatkan "tanggungjawabnya" terhadap sebuah objek.

OOA biasanya menggunakan kartu CRC (Component, Responsibility, Collaborator) untuk membangun kelas-kelas yang akan digunakan atau menggunakan UML (Unified Modeling Language) pada bagian diagram use case, diagram kelas, dan diagram objek.[24].

2.3 UML (Unified Modelling Language)

Unified Modelling Language (UML) adalah sebuah “bahasa” yang telah menjadi standar dalam industry visualisasi, merancang, dan mendokumentasikan sistem peranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem.

UML dapat digunakan untuk membuat model untuk semua jenis perangkat lunak, dimana perangkat lunak tersebut dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta ditulis dalam bahasa pemrograman apapun. Tetapi karena UML juga menggunakan class dan operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa berorientasi objek.

Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi dan syntax. Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti lunak. Setiap bentuk memiliki makna tertentu, dan UML syntax mendefinisikan begaimana bentuk-bentuk tersebut dapat dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang telah ada sebelumnya yaitu Grady Booch OOD (Object Oriented Design), Jim Rumbaugh OMT (Object Modeling Technique) dan Ivar Jacobson OOSE (Object Oriented Software Engineering).

2.3.1 Diagram UML

Pada UML 2.6 terdiri dari 13 macam diagram yang dikelompokkan dalam 3 kategori. Pembagian kategori dan macam-macam diagram tersebut dapat dilihat pada gambar di bawah :

Gambar 2.7 Diagram UML[19]

Berikut ini penjelasan singkat dari pembagian katagori tersebut.

1. Structure diagrams yaitu kumpulan diagram yang digunakan untuk

menggambarkan suatu struktur statis dari sistem yang dimodelkan.

2. Behavior diagrams yaitu kumpulan diagram yang digunakan untuk

menggambarkan kelakuan sistem atau rangkain perubahan yang terjadi pada sebuah sistem.

3. Interaction diagrams yaitu kumpulan diagram yang digunakan untuk

menggambarkan interaksi sistem dengan sistem lain maupun interaksi antar subsistem pada suatu sistem.

2.3.2 Use Case Diagram

Use case atau diagram use case merupakan pemodelan untuk kelakuan (behavior) sistem informasi yang akan dibuat. Use case mendeskripsikan sebuah interaksi antara satu atau lebih aktor dengan sistem informasi yang akan dibuat. Secara kasar, use case digunakan untuk mengetahui fungsi apa saja yang ada di dalam sebuah sistem informasi dan siapa saja yang berhak menggunakan fungsi- fungsi itu. Syarat pada use case adalah nama didefinisikan sesimpel mungkin dan dapat dipahami. Ada dua hal utama pada use case yaitu pendefinisian apa yang disebut aktor dan use case.

Aktor merupakan orang, proses, atau sistem lain yang berinteraksi dengan sistem informasi yang dapat dibuat di luar sistem informasi yang akan dibuat itu sendiri, jadi walaupun simbol dari aktor adalah gambar orang, tapi aktor belum tentu merupkan orang. Use case merupakan fungsionalitas yang disediakan sistem sebagai unit-unit yang saling bertukar pesan antar unit aktor[19].

Berikut adalah simbol-simbol yang ada pada diagram use case dapat dilihat pada tabel 2.1 :

2.3.3 Activity Diagram

Diagram aktivitas atau Activity Diagram menggambarkan workflow (aliran kerja) atau aktivitas dari sebuah sistem atau proses bisnis. Yang perlu diperhatikan disini adalah bahwa diagram aktivitas menggambarkan aktivitas sistem bukan apa yang dilakukan aktor, jadi aktivitas yang dapat dilakukan oleh sistem

Diagram aktivitas juga banyak digunakan untuk mendefinisikan hal-hal berikut: 1. Rancangan proses bisnis di mana setiap urutan aktivitas yang digambarkan

merupakan proses bisnis sistem yang didefinisikan.

2. Urutan atau pengelompokan tampilan dari sistem /user interface di mana setiap aktivitas memiliki sebuah rancangan antarmuka tampilan.

3. Rancangan pengujian di mana setiap aktivitas memerlukan sebuah pengujian yang perlu didefinisikan kasus ujinya.

Berikut adalah simbol-simbol yang ada pada diagram aktivitas tabel 2.2 :

2.3.4 Sequance Diagram

Diagram sekuen menggambarkan kelakuan objek pada use case dengan mendeskrifsikan waktu hidup objek dan message yang dikirimkan dan diterima antarobjek. Oleh karena itu untuk menggambar diagram sekuen maka harus diketahui objek-objek yang terlibat dalam sebuah use case beserta metode-metode yang dimiliki kelas yang diinstansiasi menjadi objek itu.

Banyaknya diagram sekuen yang harus digambar adalah sebanyak pendefinisian use case yang memiliki proses sendiri atau yang penting semua use case yang telah didefinisikan interaksi jalannya pesan sudah dicakup pada diagram sekuen sehinga semakin banyak use case yang didefinisikan maka diagram sekuen yang harus dibuat juga semakin banyak[19].

2.3.5 Class Diagram

Diagram kelas atau class diagram menggambarkan struktur sistem dari segi pendefinisian kelas-kelas yang akan dibuat untuk membangun sistem. Kelas mimiliki apa yang disebut atribut dan metode atau operasi[19].

a. Atribut merupakan variabel-variabel yang dimiliki oleh suatu kelas. b. Operasi atau metode adalah fungsi-fungsi yang dimiliki oleh suatu kelas. Berikut adalah simbol-simbol yang ada pada diagram kelas pada tabel 2.4

2.4 Tools yang digunakan

Tools adalah unsur penting dalam pembangunan sebuah aplikasi. Ada beberapa tools yang akan digunakan disini, diantaranya :

1. Unity

Unity merupakan sebuah game engine dan editor, yang memungkinkan pengembang membuat object, meng-import external asset dan menggabungkan semuanya dengan menggunakan kode secara efisien dan cepat dengan versi 4.3. Prinsip dari Unity sendiri adalah agar pengembang dapat melakukan aktivitasnya dengan menggabungkan script dan membuat beberapa variabel. Unity juga mendukung kemampuan networking dan dapat digunakan pada banyak platform. Scripting di dalam Unity dapat menggunakan bahasa pemrograman, yaitu C#. Pengembang game dapat menggunakan bahasa pemrograman tersebut dalam satu proyek miliknya. Beberapa konsep penting di dalam scripting yang harus pengembang mengerti adalah[20]:

a. Function Update(){}

Merupakan container dari kode yang dieksekusi berkali-kali setiap detik (per –frame).

Merupakan refence untuk komponen transform game object, yang mendefinisikan posisi, rotasi, dan skala dari setiap game object. Setiap object memiliki transform.

c. Rotate()

Merupakan sebuah fungsi yang ada pada komponen transform. Angka-angka yang berada di dalam koma merepresentasikan derajat dari rotasi untuk setiap axis di dalam 3D space : X,Y,Z.

d. Time.deltaTime

Merupakan anggota dari kelas Time yang berjalan pada setiap detik, sehingga sebuah game object dapat berputar dengan kecepatan yang sama seberapa pun frame per detik yang dapat dihasilkan setiap detik. Misalnya : 5 * Time.deltaTime artinya 5 derajat perdetik

e. C#

C# (baca : See-Sharp) adalah bahasa pemrograman baru yang diciptakan Microsoft yang digunakan oleh banyak developer .NET untuk mengembangkan aplikasi dengan platform .NET.

2. Adobe photoshop

Adobe Photoshop, atau biasa disebut Photoshop, adalah perangkat lunak editor citra buatan Adobe Sistems yang dikhususkan untuk pengeditan foto/gambar dan pembuatan efek. Photoshop memiliki kemampuan untuk membaca dan menulis gambar berformat raster dan vektor seperti .png, .gif, .jpeg, dan lain-lain. Photoshop juga memiliki beberapa format file khas[22]:

a. PSD (Photoshop Document) format yang menyimpan gambar dalam bentuk layer, termasuk teks, mask, opacity, blend mode, channel warna, channel alpha, clipping paths, dan setting duotone. Kepopuleran photoshop membuat format file ini digunakan secara luas, sehingga memaksa programer program penyunting gambar lainnya menambahkan kemampuan untuk membaca format PSD dalam perangkat lunak mereka.

b. PSB' adalah versi terbaru dari PSD yang didesain untuk file yang berukuran lebih dari 2 GB.

c. PDD adalah versi lain dari PSD yang hanya dapat mendukung fitur perangkat lunak Photshop Deluxe

31

3.1 Analisis Masalah

Pada analisis masalah game yang umumnya tingkat kesulitan berupa tahapan yang dimulai dari tingkatan termudah hingga tahapan tersulit. Namun ada pula game yang berada pada satu level dengan tingkat kesulitan yang berawal dari tingkat termudah hingga tingkat tersulit, hanya saja pada game dengan satu level ini, jika tingkat kesulitan berada dalam tingkat tersulit, maka game akan tetap pada tingkat kesulitan tersebut atau tidak dapat kembali ke tingkat awal (mudah). Dengan masalah tersebut, game terasa membosankan karena game mudah ditebak. Dengan mengimplementasikan logika fuzzy pada tingkat kesulitan game evakuasi korban banjir diharapkan tingkat kesulitan pada game ini dapat kembali ke tingkat termudah atau sedang saat tingkat kesulitan dalam game berada ditingkat tersulit.

3.2 Analisis Game

Dalam game ini terdapat 1 tahap permainan yaitu tahap pengevakuasian, yang dimana pemain akan mulai mengevakuasi korban-korban yang ada diatas rumah korban masing-masing. Pada tahap game pengevakuasian ini algoritma logika fuzzy dijalankan, dimana ada kondisi yang menentukan apakah saat pengevakuasian sudah dimulai tingkat kesulitan mudah, sedang, atau sulit. Kondisi itu berhubungan dengan jumlah korban yang dibawa pemain interval 0 hingga 6 korban dan cuaca mendung, gerimis, dan hujan deras yang akan terjadi secara acak dalam 10 detik.

Pada tahapan ini akan mendeskripsikan game yang akan dibangun. Pada bagian ini terdiri dari storyline, gameplay, jenis permainan, tingkat kesulitan, dan analisis scoring.

Tabel 3.1 Game Yang Dibangun Game Yang Dibangun

Desain Grafis 2D

Karakter Utama

Karakter Pemuda

Pergerakan Karakter

Pergerakan karakter digerakan oleh pemain. Pergerakan hanya ke kanan dan ke kiri

Rintangan Batang kayu, ular , dan arus listrik

Target Mengumpulkan banyak korban untuk di evakuasi

Gameplay Untuk menyelesaikan permainan pemain harus melewati halangan-halangan yang ada dan mengumpulkan banyak korban yang nantinya akan dibawa ke pos evakuasi.

3.2.1 Skenario Game

Skenario dalam game tingkat kesulitan evakuasi korban banjir dapat dilihat alur permainannya sebagai berikut:

1. Pemain akan langsung berada didaerah yang sudah terkena bencana banjir. 2. Pemain langsung berada disebuah perahu karet.

3. Pemain akan mengendalikan perahu karet dengan arah kanan dan kiri untuk mengevakuasi korban banjir dan juga untuk menghindar dari halangan-halangan yang ada di daerah banjir.

4. Pemain mendapatkan waktu 5 menit untuk mengevakuasi , dalam waktu tersebut pemain harus mengumpulkan banyak korban banjir

5. Jika pemain mengumpulkan sedikit korban dalam waktu 5 menit maka pemain diharuskan untuk mengulang ke awal pengevakuasian.

6. Jika mendapat banyak korban, pemain akan mendapatkan poin dari jumlah korban yang dibawa dan juga dari jumlah halangan yang terlewati.

3.2.2 Tahap Permainan

Dalam game yang akan dibangun terdapat 1 tahap permainan, yaitu: 1. Pengevakuasian Korban

evakuasi korban banjir. 2. Tingkat kesulitan

Tantangan merupakan kejadian yang muncul dalam game dan dapat diselesaikan oleh pemain dengan berbagai macam cara. Terdapat tiga kondisi tingkat kesulitan yang terdapat pada tabel berikut :

Tabel 3.2 kondisi tingkat kesulitan

Aturan Rintangan Skenario Permainan

Mudah Batang pohon

Pemain dihadapkan dengan batang pohon. Bila pemain terkena laju batang pohon maka health pemain akan berkurang.

Sedang

Batang pohon

Pemain dihadapkan dengan batang pohon. Bila pemain terkena laju batang pohon maka health pemain akan berkurang.

Kemunculan ular

Pemain dihadapkan dengan adanya ular yang tiba-tiba muncul untuk mengganggu proses evakuasi , jika pemain terkena laju ular maka health pemain akan berkurang dan kuota korban akan berkurang satu.

Sulit

Batang pohon

Pemain dihadapkan dengan batang pohon. Bila pemain terkena laju batang pohon maka health pemain akan berkurang.

Kemunculan ular

Pemain dihadapkan dengan adanya ular yang tiba-tiba muncul untuk mengganggu proses evakuasi , jika pemain terkena laju ular maka health pemain akan berkurang dan kuota korban akan berkurang satu.

Kabel listrik yang terputus

Pemain dihadapkan dengan kabel listrik yang tiba-tiba terputus dan mengeluarkan arus listrik. Jika pemain terkena arus listrik maka akan mengurangi health pemain dan kuota korban akan berkurang dua

3.3 Analisis Masukan

Terdapat 2 variabel pada game ini, dimana variabel ini akan menentukan hasil output pada game . Adapun variabel yang digunakan adalah:

2. Cuaca yang muncul saat terjadinya pengevakuasian korban  Mendung, Gerimis, Hujan Deras. Cuaca ditentukan secara acak setiap 5 hingga 10 detik sekali, jadi ketika user memainkan game, tidak mesti cuaca sedang di mendung.

a. Mendung (cuaca)  Kondisi dimana awan menghitam yang berkemungkinan akan terjadinya hujan.

b. Gerimis (cuaca)  Kondisi dimana hujan turun dengan intensitas rendah c. Hujan Deras (cuaca)  Kondisi dimana hujan turun dengan intensitas

tinggi.

Gambar 3.1 Grafik derajat keanggotaan penentuan kondisi cuaca

Fungsi Keanggotaan pada grafik derajat keanggotaan penentuan kondisi cuaca

5 10 20 25

1

30 Mendung Gerimis Hujan Deras

0 (cuaca) µ(x) 6 0,8 0,2

a. (3.1)

b. (3.2)

c. (3.3)

3. Kuota korban yang dibawa oleh pengevakuasi  Sedikit, Banyak Penentuan korban, berdasarkan korban yang dibawa oleh pemain, jika pemain tidak membawa korban atau hanya membawa 2 korban saja maka akan dianggap kuota sedikit, sedangkan 3 hingga 6 korban dianggap Penuh.

a. Sedikit (kuota)  Korban evakuasi hanya sedikit, dalam kuota perahu 6 orang , yang terevakuasi hanya 2 orang.

b. Penuh (kuota)  Korban evakuasi memenuhi kuota perahu.

Gambar 3.2 Grafik derajat keanggotaan penentuan kuota korban

Fungsi Keanggotaan pada grafik derajat keanggotaan penentuan kuota korban

2 6

1 Sedikit Banyak

0 4

(kuota)

µ(x)

3

a. . (3.4)

b. (3.5)

3.3.2 Analisis Scoring

Pada game yang akan dibangun terdapat poin yang diberikan setiap menyelesaikan permainan. Poin akan hilang atau kembali ke keadaan awal jika pemain tidak menyelesaikan misi dalam setiap tahapnya. Jumlah poin yang didapat dari setiap misi yang dilakukannya sebagai berikut:

a. Melewati halangan yang ada = +50 b. Membawa korban =+100

3.4 Analisis Algoritma Logika Fuzzy

Algoritma logika fuzzy akan diterapkan pada kejadian-kejadian saat evakuasi korban banjir, dimana saat evakuasi akan terjadi cuaca yang berubah, halangan yang muncul, kuota korban dan tingkat kesulitan yang akan dihadapi pemain. Berikut adalah ilustrasi logika fuzzy yang dapat dilihat pada tabel Input dan Output Algoritma logika fuzzy:

Tabel 3.3 Input dan Output Algoritma logika fuzzysaat Perjalanan Evakuasi

Cuaca Kuota Aturan

Mendung Sedikit Mudah

Mendung Banyak Sedang

Gerimis Sedikit Mudah

Gerimis Banyak Sulit

Hujan Deras Sedikit Sedang

Hujan Deras Banyak Sulit

Pada tabel Input dan output yang digunakan untuk menentukan tingkat kesulitan yang akan dihadapi pemain. Input dan Output tersebut memiliki tingkat

kesulitan yang berbeda, berikut penjelasan dari masing-masing Input dan output tersebut Adapun himpunan fuzzy pada game ini adalah nya adalah:

1. Mudah 2. Sedang 3. Sulit

Rule logika fuzzy Saat Perjalanan Evakuasi 3 x 2 = 6

1. IF cuaca is Mendung AND kuota is Sedikit THEN Tantangan is Mudah 2. IF cuaca is Mendung AND kuota is Banyak THEN Tantangan is Sedang 3. IF cuaca is Gerimis AND kuota is Sedikit THEN Tantangan is Mudah 4. IF cuaca is Gerimis AND kuota is Banyak THEN Tantangan is Sulit 5. IF cuaca is Hujan Deras AND kuota is Sedikit THEN Tantangan is Sedang 6. IF cuaca is Hujan Deras AND kuota is Banyak THEN Tantangan is Sulit

Penentuan Kondisi Cuaca

Penjelasan cuaca merupakan nilai yang dihasilkan secara acak diperkirakan setiap 10 detik yang nantinya akan digunakan untuk menentukan kondisi hujan pada saat pengevakuasian , yang terdiri dari mendung, gerimis, dan hujan deras.

Penentuan Jumlah Korban yang Dibawa

Penjelasan kuota merupakan nilai yang dihasilkan dari banyaknya korban yang dibawa dimana korban yang dibawa terdiri dari Sedikit dan Banyak.

Contoh kasus

1. Misal didapatkan nilai cuaca sebesar 6. Pada proses ini maka nilai crips Input cuaca 6 dikonversi ke nilai fuzzy dengan cara, cuaca 6 berada pada nilai linguistik Mendung dan Gerimis. Derajat keanggotaan untuk gerimis dihitung menggunakan rumus yang dapat dilihat pada gambar 2.3. Maka didapat derajat keanggotaan cuaca mendung dengan rumus (gambar 2.3) dimana c = 5 dan d = 10 sehingga derajat keanggotaan Mendung = - ( 10 – 6 ) / ( 10 – 5 ) = 4/5. dimana a=5 dan b= 10 sehingga derajat keanggotaan Gerimis =(10-5) / (10-5) = 1/5. Dari hasil diatas akan didapat grafik derajat keanggotaan dari kasus Penentuan Kondisi Cuaca yang dapat dilihat pada

gambar 3.1

2. Misal didapatkan nilai kuota sebesar 3. Pada proses ini maka nilai crips Input kuota 3 dikonversi ke nilai fuzzy dengan cara, kuota 3 berada pada nilai linguistik sedikit dan Banyak. Derajat keanggotaan untuk Sedikit dihitung menggnakan rumus (gambar 2.3) dimana c = 2 dan d = 4 sehingga derajat keanggotaan Sedikit = - ( 4 – 3 ) / ( 4 – 2 ) = ½. Derajat keanggotaan untuk Penuh menggunakan rumus (gambar 2.3) dimana a=2 dan b= 4 sehingga derajat keanggotaan Banyak =(3-2) / (4-2) = ½. Maka akan didapat grafik derajat keanggotaan dari kasus Penentuan Jumlah Korban yang dibawa yang dapat dilihat pada gambar 3.2.

Dari hasil perhitungan tersebut maka terdapat aturan yang telah ada pada tabel Input dan output menggunakan aturan Conjunction ( ) dengan memilih derajat keanggotaan minimum sehingga diperoleh :

1. IF cuaca is Mendung (4/5) AND kuota is Sedikit (1/2) THEN Tantangan is Mudah (1/2)

2. IF cuaca is Mendung (4/5) AND kuota is Banyak (1/2) THEN Tantangan is Sedang (1/2)

3. IF cuaca is Gerimis ( 0 ) AND kuota is Sedikit (1/2) THEN Tantangan is Mudah (1/5)

4. IF cuaca is Gerimis ( 0 ) AND kuota is Banyak (1/2) THEN Tantangan is Sulit (1/5)

5. IF cuaca is Hujan Deras ( 0 )AND kuota is Sedikit (1/2) THEN Tantangan is Sedang (1/2)

6. IF cuaca is Hujan Deras ( 0 ) AND kuota is Banyak (1/2) THEN Tantangan is Sulit (1/2)

Dari hasil diatas maka akan melanjutkan menggunakan proses inference menggunakan model Sugeno dengan Aturan Disjunction (v) dimana memilih derajat keangotaan maksimum Sehingga dihasikan , yaitu :

1. Tantangan is Mudah (1/2) tantangan is Mudah (1/2) Dihasilkan tantangan is Mudah (1/2)

is Sedang (1/2)

3. Tantangan is Sulit ( 0 ) tantangan is Sulit (1/2) dihasilkan tantangan is Sulit (1/2)

Maka akan di dapat grafik derajat keanggotaan model sugeno pada gambar 3.3 :

Gambar 3.3 Grafik Derajat keanggotaan model sugeno

Dilanjutkan dengan proses defuzzyfication menggunakan model sugeno Dengan menggunakan weighted average method untuk proses defuzzyfication maka didapat hasil dengan rumus 2.1. Maka akan didapatkan hasil perhitungan sebagai berikut :

(3.6)

dari kesimpulan proses defuzzyfication menggunakan model sugeno

1. Nilai yang didapat dari proses defuzzyfication tersebut selanjutnya digunakan untuk penentuan keputusan dengan aturan sebagai berikut

2. Mudah 0-20 3. Sedang 21-40 4. Sulit 41-60

Hasil nilai dari keputusan = 60 adalah Sulit.

Dari hasil tingkat tantangan Sulit maka akan muncul kejadian-kejadian pada tabel 3.2. 20 40 0 1 Mudah Sulit µ Tantangan Sedang 60 1/2 30

3.5 Analisis Kebutuhan Perangkat Lunak

Perangkat lunak yang digunakan dalam sebuah sistem merupakan perintah-perintah yang diberikan kepada perangkat keras agar bisa saling berinteraksi diantara keduanya.

1. Pengembang

Spesifikasi perangkat lunak yang digunakan pengembang untuk membangun game ini dapat dilihat pada tabel berikut :

Tabel 3.4 Spesifikasi Perangkat Lunak Pengembang

Nama Perangkat Lunak Spesifikasi

Sistem Operasi Microsoft Windows 7 SP1

Tools

- Unity 3D 4.3

- Adobe Photoshop CS6 - DirectX 11

2. Pengguna

Spesifikasi minimum perangkat lunak yang dibutuhkan pengguna untuk memainkan game ini dapat dilihat pada tabel berikut :

Tabel 3.5 Spesifikasi Minimum Perangkat Lunak Pengguna

Nama Perangkat Lunak Spesifikasi

Sistem Operasi Microsoft Windows XP SP2

Tools - Unity Web Player - DirectX 9 3. Pengembang

Spesifikasi perangkat keras yang digunakan pengembang untuk membangun game ini dapat dilihat pada tabel berikut:

Tabel 3.6 Spesifikasi Perangkat Keras Pengembang

Nama Perangkat Spesifikasi

Processor Intel Core 2 Duo 2.20 GHz

RAM 4 GB

Harddisk 500 GB

Monitor Resolusi 1366 x 768

Mouse dan keyboard Standar 4. Pengguna

Berdasarkan system requirement yang ada pada website Unity3D spesifikasi minimum perangkat keras bagi pengguna untuk dapat memainkan game ini dengan baik dapat dilihat pada tabel berikut :

Tabel 3.7 Spesifikasi Minimum Perangkat Keras Pengguna

Nama Perangkat Spesifikasi

Processor 1.80 GHz

RAM 2 GB

VGA Card 250 MB

Harddisk Tersedia 100 MB

Monitor Resolusi 800 x 600

Mouse dan keyboard Standar

Dengan spesifikasi yang lebih rendah maka pengguna tidak akan memainkan aplikasi game dengan maksimal seperti mengalami ketersendatan atau gambar yang kabur.

3.5.1 Analisis Pengguna

Pada analisis pengguna ini akan mencakup analisis beberapa parameter terhadap calon pengguna dari aplikasi.

1. User Knowledge and Experience dari target pengguna yang akan

menggunakan game

Game yang akan dibangun ini bisa digunakan oleh kalangan apapun, tetapi pengetahuan dan pengalaman akan memudahkan pengguna dalam penggunaannya. Berikut ini klasifikasi knowledge and experience dari aplikasi:

Tabel 3.8 Analisis klasifikasi knowledgeandexperience

Educational Level Game ini bisa digunakan oleh berbagai kalangan seperti pelajar, mahasiswa hingga masyarakat awam

Reading Level Game ini bisa digunakan oleh berbagai level pendidikan dengan reading level rendah

Computer Literacy Game ini bisa digunakan oleh pengguna yang memiliki kemampuan komputer yang rendah

Task Experience Game ini bisa digunakan oleh pengguna dengan pengalaman game yang rendah

System Experience Game ini bisa digunakan oleh pengguna dengan pengalaman komputer yang rendah

Application Experience Game ini bisa digunakan dalam semua sistem operasi Windows minimal XP

Native Language Game ini menggunakan bahasa Indonesia dan bahasa inggris Use of Other System Game ini bisa dijalankan tanpa perlu install aplikasi lain

2. User Physical Characteristic

Keadaan fisik seseorang mungkin akan berpengaruh pada penggunaan aplikasi game ini. Ada hal-hal yang harus diperhatikan juga terhadap pengguna dari karakteristik fisiknya untuk dapat menggunakan aplikasi ini yaitu, color blind, handedness, dan gender.

Tabel 3.9 Analisis Users Physical Characteristic Age 9 tahun ke atas

Gender Pria dan wanita Handedness Kanan dan kiri

Disabilities Pengguna yang buta tidak akan bisa menggunakan game ini, untuk yang penglihatannya kurang dan tuli masih dapat memainkan tetapi tidak akan optimal.

3.5.2 Analisis Kebutuhan Fungsional

Analisis kebutuhan fungsional menggambarkan proses kegiatan yang akan diterapkan dalam sebuah sistem dan menjelaskan kebutuhan yang diperlukan sistem agar sistem dapat berjalan dengan baik sesuai kebutuhan. Analisis

kebutuhan fungsional dimodelkan dengan menggunakan UML (Unified Modeling Language).

3.5.3 Use Case Diagram

Diagram use case menggambarkan hubungan antara aktor dan sistem yang dibangun. Perancangan proses-proses yang terdapat pada game yang akan dibangun akan digambarkan dengan diagram use case. Interaksi antara aktor dengan aplikasi game yang akan dibangun digambarkan pada diagram use case pada Gambar 3.4

Gambar 3.4 Use case DiagramGame yang akan dibangun

3.5.4 Definisi Aktor

Aktor merupakan orang, proses, atau sistem lain yang berinteraksi dengan sistem sistem yang akan dibangun [19]. Definisi aktor diterangkan pada tabel berikut :

Tabel 3.10 Definisi Aktor

No Aktor Deskripsi

1. Pemain Pemain atau orang yang memainkan game

3.5.5 Definisi Use case

Use case merupakan fungsionalitas yang disediakan sistem sebagai unit-unit yang saling bertukar pesan antar unit-unit atau aktor [19]. Definisi use case diterangkan pada tabel 3.11 :

Tabel 3.11 Definisi Use case No. Use case Deskripsi

1. Mulai Game Proses untuk masuk dalam game evakuasi

2. Acak Cuaca Proses untuk mengacak (random) kondisi cuaca

yang akan muncul pada game

3. Jumlah Kuota Proses untuk menghitung jumlah kuota yang ada

dalam game

4. Menggerakan Perahu Proses untuk menggerakan perahu dalam game

5. Ambil Korban Proses untuk mengambil korban dalam game

6. Mengembalikan korban ke pos Proses untuk mengembalikan korban ke pos dalam game

7. Ambil Makanan Proses untuk mengambil makanan dalam game

8. Menghilangkan Batang Pohon Proses untuk mengklik halangan berupa batang pohon yang ada dalam game

9. Menghilangkan Ular Proses untuk mengklik halangan berupa ular yang ada dalam game

10. Menghilangkan Kabel Listrik yang Terputus

Proses untuk mengklik halangan berupa kabel listrik yang terputus yang ada dalam game

11. Lihat Petunjuk Proses untuk melihat petunjuk atau panduan cara bermain

12. Pengaturan Suara Proses untuk mengatur suara menjadi ON atau OFF

3.5.6 Skenario Use case

Setiap use case dilengkapi dengan skenario. Skenario use case adalah alur jalannya proses use case dari sisi aktor dan sistem [19]. Berikut adalah skenario jalannya masing-masing use case yang telah didefinisikan sebelumnya :

1. Skenario Use case Mulai Game

Tabel 3.12 Scenario Use case Mulai Game Nama Use case Mulai Game

Aktor User

Type Primary, Essential

Tujuan Menampilkan layar utama pada game dan check Fuzzy Kondisi Awal Aplikasi Game yang belum dijalankan

Aksi Aktor Reaksi Sistem

Skenario Normal 1. Mulai Aplikasi

2. Menampilkan Menu Utama

3. Pilih Menu Play

4. Menampilkan Layar Utama Game

5. Acak Cuaca dan Jumlah Kuota

6. Hitung Nilai Derajat Keanggotaan Fuzzy

2. Skenario Use case Acak Cuaca

Tabel 3.13 Scenario Use case Acak Cuaca Nama Use case Acak Cuaca

Aktor User

Type Primary, Essential

Tujuan Menampilkan Acak Cuaca pada Game

Kondisi Awal Cuaca yang muncul pada saat game dimulai

Aksi Aktor Reaksi Sistem

Skenario Normal

3. Skenario Use case Jumlah Kuota

Tabel 3.14 Scenario Use case Jumlah Kuota Nama Use case Jumlah Kuota

Aktor User

Type Primary, Essential

Tujuan Menampilkan Jumlah Kuota yang ada pada game

Kondisi Awal Pemain tidak memiliki kuota dalam perahu

Aksi Aktor Reaksi Sistem

Skenario Normal 1. Pilih menu Play

2. Menampilkan Layar Utama Game

3. Acak Cuaca

4. Skenario Use case Menggerakan Perahu

Tabel 3.15 Scenario Use case Menggerakan Perahu Nama Use case Menggerakan Perahu

Aktor User

Type Primary, Essential

Tujuan Menampilkan cara menggerakan perahu dalam game

Kondisi Awal Pemain berada diatas perahu

Aksi Aktor Reaksi Sistem

Skenario Normal

5. Skenario Use case Ambil Korban

Tabel 3.16 Scenario Use case Ambil Korban Nama Use case Ambil Korban

Aktor User

1. Pilih menu Play

2. Menampilkan Layar Utama Game

3. Check Kuota pada NPC

1. Tekan tombol A jika ingin perahu bergerak ke kiri

2. Gerak Perahu ke kiri 3. Tekan tombol D jika ingin perahu

bergerak ke kanan

Type Primary, Essential

Tujuan Mengambil korban dalam game

Kondisi Awal Pemain berada dekat dengan korban

Aksi Aktor Reaksi Sistem

Skenario Normal

1. Klik dan Drag korban ke perahu

2. Kuota korban bertambah

3. Nilai bertambah

6. Skenario Use case Mengembalikan Korban ke Pos

Tabel 3.17 Scenario Use case Mengembalikan korban ke pos Nama Use case Mengembalikan korban ke pos

Aktor User

Type Primary, Essential

Tujuan Mengurangi kuota korban yang dibawa

Kondisi Awal Pemain memiliki lebih dari satu kuota korban

Aksi Aktor Reaksi Sistem

Skenario Normal

1. Pemain menuju pos evakuasi

2. Kuota korban berkurang

3. Nilai bertambah

7. Skenario Use case Ambil Makanan

Tabel 3.18 Scenario Use case Ambil Makanan Nama Use case Ambil Makanan

Aktor User

Type Primary, Essential

Tujuan Menambah health pada pemain pada game

Kondisi Awal Pemain dekat dengan makanan yang ada pada game

Aksi Aktor Reaksi Sistem

Skenario Normal

1. Klik dan Drag makanan ke perahu

2. Health pemain bertambah

8. Skenario Use case Menghilangkan Batang Pohon

Tabel 3.19 Scenario Use case Menghilangkan Batang Pohon Nama Use case Menghilangkan Batang Pohon

Aktor User

Type Primary, Essential

Tujuan Menghilangkan tantangan batang pohon yang muncul

Kondisi Awal Tantangan batang pohon muncul pada game

Aksi Aktor Reaksi Sistem

Skenario Normal

1. Menghilangkan batang pohon

yang muncul

2. Batang pohon menghilang

3. Nilai bertambah

9. Skenario Use case Menghilangkan Ular

Nama Use case Menghilangkan Ular

Aktor User

Type Primary, Essential

Tujuan Menghilangkan tantangan ular yang muncul

Kondisi Awal Tantangan ular muncul pada game

Aksi Aktor Reaksi Sistem

Skenario Normal

1. Menghilangkan ular yang muncul

2. Ular menghilang

3. Nilai bertambah

10. Skenario Use case Menghilangkan Kabel Listrik yang Terputus Tabel 3.21 Scenario Use case Menghilangkan Kabel Listrik yang Terputus Nama Use case Menghilangkan Kabel Listrik yang Terputus

Aktor User

Type Primary, Essential

Tujuan Menghilangkan tantangan Kabel Listrik yang Terputus yang muncul Kondisi Awal Tantangan Kabel Listrik yang Terputus muncul pada game

Aksi Aktor Reaksi Sistem

Skenario Normal

1. Menghilangkan Kabel Listrik yang Terputus yang muncul

2. Kabel listrik yang terputus menghilang

11. Skenario Use case Lihat Petunjuk

Tabel 3.22 Scenario Use case Lihat Petunjuk Nama Use case Lihat Petunjuk

Aktor User

Type Primary, Essential

Tujuan Menampilkan isi menu petunjuk permainan

Kondisi Awal Pemain berada pada menu utama game

Aksi Aktor Reaksi Sistem

Skenario Normal

1. Menampilkan Menu utama 2. Pilih Menu lihat petunjuk

3. Menampilkan layar petunjuk permainan 4. Klik tanda panah jika ingin melihat

kembali isi petunjuk yang lain

5. Menampilkan Isi Petunjuk Yang Lain 6. Klik kembali jika ingin kembali ke

menu utama

7. Menampilkan Menu Utama

12. Skenario Use case Pengaturan Suara

Tabel 3.23 Scenario Use case Pengaturan Suara Nama Use case Pengaturan Suara

Type Primary, Essential

Tujuan Menampilkan pengatur suara pada game

Kondisi Awal Tampilan pengatur ON atau OFF pada layar

Aksi Aktor Reaksi Sistem

Skenario Normal

1. Menampilkan Menu utama 2. Inisialisasi suara = ON atau TRUE 3. Klik tombol OFF pada layar menu

utama

4. Suara = OFF atau FALSE

3.5.7 Activity Diagram

Diagram activity menggambarkan proses-proses yang terjadi mulai aktivitas dimulai sampai aktivitas berhenti pada sistem yang sedang dirancang. Bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir.

1. Activity Diagram Mulai Game

Proses ini terjadi saat pemain memilih Menu play pada Menu utama. Selanjutnya, sistem akan masuk ke scene game. Berikut adalah activity diagram mulai game yang terdapat pada gambar 3.5

Gambar 3.5 Activity Diagram Mulai Game

2. Activity Diagram Acak Cuaca

Proses ini terjadi saat pemain masuk dalam game. Selanjutnya, sistem akan melakukan pengacakan cuaca. Berikut adalah activity diagram Acak Cuaca yang terdapat pada gambar 3.6

Gambar 3.6 Activity Diagram Acak Cuaca

3. Activity Diagram Jumlah Kuota

Proses ini terjadi saat pemain masuk dalam game. Selanjutnya, sistem akan melakukan pengecekan jumlah kuota. Berikut adalah activity diagram Jumlah Kuota yang terdapat pada gambar 3.7

Gambar 3.7 Activity Diagram Jumlah Kuota

4. Activity Diagram Menggerakan Perahu

Proses ini terjadi saat pemain masuk dalam game. Selanjutnya, pemain akan melakukan aksi untuk menggerakan perahu. Berikut adalah activity diagram Menggerakan Perahu yang terdapat pada gambar 3.8

5. Activity Diagram Ambil Korban

Proses ini terjadi saat pemain masuk dalam game. Selanjutnya, pemain akan melakukan aksi mengambil korban evakuasi. Berikut adalah activity diagram Ambil Korban yang terdapat pada gambar 3.9

Gambar 3.9 Activity Diagram Ambil Korban

6. Activity Diagram Mengembalikan Korban ke Pos

Proses ini terjadi saat pemain masuk dalam game. Selanjutnya, pemain akan melakukan aksi mengurangi kuota korban. Berikut adalah activity diagram Mengembalikan Korban ke Pos yang terdapat pada gambar 3.10

Gambar 3.10 Activity Diagram Mengembalikan Korban ke Pos

7. Activity Diagram Ambil Makanan

Proses ini terjadi saat pemain masuk dalam game. Selanjutnya, pemain akan melakukan aksi pengambilan makanan untuk menambah health. Berikut adalah activity diagram Ambil Makanan yang terdapat pada gambar 3.11

76

Gambar 4.12 Pengujian Input Logika Fuzzy hasil Tingkat Kesulitan dan Derajat Keanggotaan rule 3

Gambar 4.13 Representasi hasil pengujian rule 3 4. Pengujian Rule ke 4

Gambar 4.14 Pengujian Input Logika Fuzzy hasil Tingkat Kesulitan dan Derajat Keanggotaan rule 4

Gambar 4.15 Representasi hasil pengujian rule 4

5. Pengujian Rule ke 5

IF cuaca is Hujan Deras AND kuota is Sedikit THEN Tantangan is Sedang

78

Gambar 4.16 Pengujian Input Logika Fuzzy hasil Tingkat Kesulitan dan Derajat Keanggotaan rule 5

Gambar 4.17 Representasi hasil pengujian rule 5 6. Pengujian Rule ke 6

Gambar 4.18 Pengujian Input Logika Fuzzy hasil Tingkat Kesulitan dan Derajat Keanggotaan rule 6

Gambar 4.19 Representasi hasil pengujian rule 6

Input Output Item yang keluar

Cuaca Mendung dan Kuota Sedikit

Mudah Batang Pohon

Cuaca Mendung dan Kuota Banyak

80

Cuaca Gerimis dan Kuota Sedikit

Mudah Batang Pohon

Cuaca Gerimis dan Kuota Banyak

Sulit Batang Pohon, Ular dan Kabel Listrik yang Terputus

Cuaca Hujan Deras dan Kuota Sedikit

Sedang Batang Pohon dan Ular

Cuaca Hujan Deras dan Kuota Banyak

Sulit Batang Pohon, Ular dan Kabel Listrik yang Terputus

4.1.6 Kesimpulan Pengujian

Dari hasil pengujian Implementasi Logika Fuzzy didapatkan kesimpulan bahwa hasil pengujian sesuai dengan rule yang ada dalam sistem fuzzy.

81

BAB V

KESIMPULAN DAN SARAN

Pada bab ini berisikan kesimpulan dari hasil penelitian yang telah dilakukan serta saran untuk perbaikan dan pengembangan penelitian lebih lanjut.

5.1 Kesimpulan

Berdasarkan hasil yang didapatkan dalam penelitian dan penyusunan skripsi ini serta disesuaikan dengan tujuan, maka diperoleh kesimpulan bahwa dalam implementasi logika fuzzy dapat memberikan gambaran perubahan kondisi yang harus dihadapi pemain dalam game serta pengimplementasian tingkat kesulitan pada game evakuasi korban banjir yang dapat kembali ke tingkat mudah saat game berada pada tingkat tersulit dan tidak mudah ditebaknya tingkat kesulitan dalam permainan.

5.2 Saran

Berdasarkan hasil dari penelitian dan implementasi, maka dapat diberikan saran-saran yaitu penambahan parameter pada algoritma Logika Fuzzy agar representasi keputusan yang di lakukan NPC karakter utama dapat lebih akurat dan dapat lebih dinamis.