BAB II TINJAUAN PUSTAKA
II.3 Perancangan Game Menggunakan UML, Scriptwriting dan Storyboard 20
Berdasarkan [10], proses pengembangan suatu software berbasis objek menggunakan UML. Sedangkan jalan cerita/gameplay game sendiri dapat dijabarkan pada scriptwriting dan storyboard [13].
II.3.1
UMLUnified Modeling Language (UML) adalah sebuah bahasa pemodelan berstandar internasional yang digunakan untuk menspesifikasikan, memvisualisasikan, membangun, dan mendokumentasikan rancangan dari sebuah perangkat lunak yang berorientasi objek. UML dibuat untuk menghilangkan kerancuan di antara notasi-notasi yang sudah ada sebelumnya.
Terdapat banyak diagram dalam UML yang dapat digunakan untuk mendesain suatu sistem, tidak harus semua diagram dibuat, tetapi sangat membantu karena diagram yang dibuat dapat membantu analisis yang sangat cermat. Berikut ini beberapa diagram yang umumnya dibuat antara lain :
II.3.1.1 Use Case Diagram
Menurut [11], Use case diagram bertujuan utama untuk mendokumentasikan tujuan makro dari sistem dan merupakan daftar kemampuan yang harus dimiliki oleh sebuah sistem. Menurut [12] elemen-elemen dalam use case diagram terdiri dari :
1. Actor
Actor adalah sebuah user eksternal yang langsung berhubungan dengan sistem, yaitu objek atau sekumpulan dari objek yang berkomunikasi secara langsung dengan sistem tetapi actor bukan bagian dari sistem.
Setiap actor mewakili sebuah objek yang bereaksi dengan berbagai cara terhadap sistem.
Sebuah actor memiliki sebuah tujuan khusus yang pasti yang digambarkan melalui interaksi yang dilakukannya terhadap sistem. Actor yang sama dapat merepresentasikan objek dari kelas yang berbeda, yang berinteraksi terhadap sistem dengan cara yang sama[13]. Lambang dari actor dapat dilihat pada Gambar berikut:
Gambar II.1 Actor
2. Use Case
Use case merupakan serangkaian transaksi yang dilakukan oleh sistem dengan berinteraksi dengan actor. Setiap use casemelibatkan satu atau lebih actor sebagaimana sistem itu sendiri. Setiap use case menyangkut rangkaian pesan antara sistem dan actor-nya.
Kondisi error juga merupakan bagian dari use case. Pada dasarnya, use case membawa semua hal yang bersangkutan dengan fungsionalitas sistem, yang terdiri dari tindakan normal yang dilakukan sistem,variasi dalam tindakan normal sistem, tanpa kecuali kondisi, kondisi error, dan pembatalan permintaan. Dalam sebuah model yang lengkap, use case membagi-bagi maupun dengan use case lainnya. Konektor dibagi menjadi tiga jenis, yaitu:
a. Asosiasi, menggambarkan hubungan antara actor dan use case yang digambarkan dengan garis anak panah yang menyentuh use case yang mengindikasikan bahwa use case diimitasi oleh pelaku di ujung lain dari garis. Simbol konektor asosiasi dengan anak panah dapat dilihat pada Gambar 2.4. garis lurus tanpa anak panah yang mengindikasikan antara use case dan actor. Simbol konektor asosiasi tanpa anak panah ditunjukkan pada Gambar 2.5.
Gambar II.3 Connector
Gambar II.4 Connector
b. Dependensi, menggambarkan hubungan antara use case dengan use case, dimana ada ketergantungan antara use case satu dengan yang lain dan digambarkan dengan garis anak panah putus-putus. Ada 2 jenis dependensi, yaitu :
Include, digunakan jika satu atau lebih use case melakukan berbagai langkah fungsionalitas yang sama. Langkah-langkah yang umum tersebut sebaiknya digabungkan ke dalam use case-nya masing-masing. Lambang dari konektor dependensi include dapat dilihat pada Gambar 2.6.
Gambar II.5 Includes
Extend, digunakan jika suatu use case dapat terdiri dari fungsionalitas yang kompleks yang terdiri dari beberapa langkah, yang membuat logika use case sulit dipahami. Untuk menyederhanakannya, langkah-langkah tersebut diekstrak menjadi use case itu sendiri. Lambang dari konektor dependensi extend dapat dilihat pada Gambar 2.7.
Gambar II.6 Extend
c. Generalisasi, bisa disebut juga dengan inherit (inheritance), yang menggambarkan hubungan antar actor atau antar use case, sehingga dapat terlihat actor atau use case yang berlaku sebagai anak yang merupakan bagian dari actor atau use case induk. Simbol dari generalisasi dapat dilihat pada Gambar 2.8.
Gambar II.7 Generalisasi
II.3.1.2 Robustness Diagram
Ivar Jacobson memperkenalkan diagram robustness yang bertujuan untuk mengidentifikasi kelas-kelas potensial yang mungkin terjadi [14]. Pada gambar II.17 adalah munculnya diagram robustness sebagai jembatan antara diagram use case dengan diagram sekuens.
Gambar II.8 Gambaran umum hubungan robustness diagram
Pada diagram robustness, dikenal 3 jenis istilah yaitu objek boundary, objek entitas, controller [14]. Objek boundary adalah objek interface antara sistem dengan dunia luar. Biasanya objek boundary adalah layar. Objek entitas adalah kelas yang bersifat informasi. Controller adalah relasi antara objek boundary dengan objek boundary, objek boundary dengan objek entitas dan objek entitas dengan objek entitas. Pada saat objek teridentifikasi maka dibuat daftar atribut dari objek tersebut. Atribut tersebut yang akan menjadi atribut pada kelas dari objek. Identifikasi nama kelas juga bisa didapatkan dari domain model dari usulan Rumbaugh. Seperti gambar berikut.
Gambar II.9 Gambaran Umum robustness diagram
Model domain merupakan daftar kelas sementara yang hanya mempunyai atribut yang terbatas. Berikut adalah simbol pada diagram robustness.
Gambar II.10 Simbol object dan action
Objek Boundary bersifat nouns dan controller bersifat verbs. Beberapa aturan ketika membuat diagram robustness adalah noun dapat berkomunikasi dengan verbs , noun tidak dapat berkomunikasi dengan noun lain dan verbs dapat berkomunikasi dengan verbs lain. Diagram robustness bukanlah diagram standar UML namun sebagai diagram alat bantu dalam mengidentifikasi diagram kelas dan sekuens. activity diagram. Saat activity diagram diaktifkan, proses dimulai dari lingkaran start tersebut dan diteruskan pada anak panah yang keluar ke arah aktivitas pertama. Lingkaran hitam yang dilingkari sebuah lingkaran di luarnya, menunjukkan titik akhir, simbol ini hanya memiliki panah masuk ke dalamnya. Saat proses mencapai titik ini, seluruh aktivitas telah selesai dan pelaksanaan activity diagram telah selesai [13].
b. Control Flow (Transition)
Control flow digambarkan dengan gambar anak panah. Control flow dapat digunakan dalam suatu aliran maupun ujung suatu aktivitas.
Control flow dimulai dari simbol ke simbol lainnya, misalnya control flow menghubungkan titik awal dan berakhir pada sebuah aktivitas.
c. Action (Activity)
Action nodes adalah sesuatu yang dilakukan atau yang terjadi dalam sebuah activity diagram. Action nodes digambarkan mirip dengan bentuk use case tetapi lebih bersudut. Nama yang action tersebut tidak akan dialihkan sampai semua aliran yang masuk sudah mencapai action tersebut.
d. Decision and Merge Nodes
Decision and Merge Nodes disebut juga decision diamondpada flowcharts. Simbol ini digambarkan dengan bentuk belah ketupat.
Ketika simbol ini digunakan sebagai decision nodemaka hanya memiliki satu aliran masuk ke node dan banyak aliran keluar.
Sebaliknya jika simbol ini digunakan sebagai merge nodes, maka ada banyak aliran masuk tetapi hanya memiliki satu aliran keluar.
Kondisi percabangan pada sebuah decision nodes bertindak sama seperti logika if else, dimana jika suatu nilai dinyatakan benar, maka nilai yang lainnya harus dinyatakan salah. Sebuah merge nodes menandakan akhir dari suatu kondisi yang dimulai oleh sebuah decision nodes.
e. Transition Forks and Joins (Synchronization Bars)
Sebuah fork digunakan untuk menggambarkan perlakuan yang paralel dan join digunakan untuk mengumpulkan banyak behavior kembali menjadi satu aliran. Ketika banyak aliran masuk dalam sebuah action, maka hal ini bisa disebut sebagai sebuah join,yang artinya arus yang keluar hanya boleh ada ketika semua arus masuk sudah mencapai actiontersebut. Sebuah diagram akan lebih jelas jika menggunakan forkdan joinketika ingin menampilkan sebuah perlakuan paralel.
Simbol-simbol pada activity diagram dapat dilihat pada Gambar II.22. Sedangkan contoh dari activity diagram ditunjukkan pada Gambar II.23.
Gambar II.11 Symbol Activity
Gambar II.12 diagram activity
II.3.1.4 Sequence Diagram
Menurut [11] Sequence diagram menunjukkan kelas-kelas dan pesan yang terkirim antara kelas-kelas tersebut, menggambarkan aliran tunggal antara objek-objek dalam sistem. Sequence diagram menggambarkan secara tidak
langsung waktu dengan mengikutkan rangkaian pesan dari kiri atas ke kanan bawah.
Sedangkan menurut [13], sequence diagram menunjukkan anggota dalam sebuah interaksi dan aliran pesan dalam interaksi tersebut, serta menunjukkan interaksi antara sistem dengan aktornya untuk melakukan semua atau sebagian dari sebuah use case. Sebuah use case memerlukan satu atau lebih sequence diagram untuk menggambarkan prosesnya. Tiap sequence diagram menunjukkan keterangan aliran kerja dari use case.
Sequence diagram dapat menunjukkan interaksi dalam skala yang besar tetapi seringkali beberapa interaksi mengandung banyak tugas yang terpisah yang dapat dikombinasikan dalam berbagai cara. Dari pada mengulang informasi, lebih baik menggambarkan sequence diagram untuk setiap tugas secara terpisah.
Sequence diagram juga dipersiapkan untuk setiap kondisi pengecualian dalam use case. Elemen dari sequence diagram menurut [11] adalah :
a. Object Lifelines
Lifeline digambarkan dengan bentuk persegi dan garis vertikal keluar dari simbol tersebut. Lifeline menggambarkan bagian dari kelas.
Garis vertikal yang keluar menghubungkan lifeline dengan pesan yang masuk maupun keluar.
Sebuah object lifeline berfungsi sebagai objek yang memiliki bagian dan fungsi dalam sebuah use case. Objek lifelines dapat merepresentasikan actor atau objek yang keduanya boleh diaktualisasikan dalam bentuk kode. Gambar dari object lifeline dapat dilihat pada Gambar II.24
Gambar II.13 Objek Lifeline
b. Activation line
Sebuah objek memiliki waktu aktif, activation line menunjukkan masa aktif dari suatu objek untuk tujuan tertentu, juga menunjukkan kapan objek tersebut aktif dipanggil dan berakhir.
Simbol dari activation line ini digambarkan dengan bentuk persegi panjang vertikal yang menumpuk pada garis vertikal lifeline sepanjang durasi bagian itu dijalankan. Sebuah objek dapat dipanggildan diakhiri berkali-kali dan sebuah lifeline digunakan untuk merepresentasikan semua bagian dari kelas itu secara keseluruhan. Gambar dari activation line dapat dilihat pada Gambar II.25.
Gambar II.14 Activation Line
c. Pesan
Pesan digambarkan dengan bentuk garis anak panah yang menghubungkan antar lifeline dengan pesan yang ditulis di atas anak panah tersebut. Pesan dapat dimulai dan diakhiri pada lifeline yang sama, yang disebut dengan nested call.
Jika garis lurus dengan ujung anak panah digambarkan dengan segitiga hitam, maka pesan yang dikirim merupakan synchronous message. Sedangkan ujung anak panah yang biasa menunjukkan synchronous message. Apabila garis digambarkan dengan garis putus-putus menunjukkan pesan dikembalikan. Gambar dari pesan dapat dilihat secara lengkap pada Gambar II.26.
Gambar II.15 Pesan
II.3.1.5 Class Diagram
Menurut [13], class diagram menyediakan notasi grafik untuk memodelkan kelas-kelas dan relasi antara kelas-kelas tersebut. Dengan demikian class diagram menggambarkan objek-objek yang ada. Class diagram berguna untuk model abstrak dan desain aktual dari program, karena singkat, mudah dimengerti dan bekerja secara benar dalam prakteknya. Elemen-elemen dari class diagram yaitu:
a. Objek
Objek adalah sebuah konsep, abstraksi, atau sesuatudengan identitas yang memiliki arti pada sebuah aplikasi. Objek seringkali muncul sebagai kata-kata yang tepat atau sebuah referensi spesifik dalam deskripsi masalah dan pemecahannya dengan user.
Pemilihan objek berdasarkan pada penilaian dan sifat dasar dari sebuah masalah sehingga menghasilkan banyak representasi yang benar. Semua objek memiliki identitas dan dapat dibedakan satu dengan yang lain. Yang dimaksud dengan identitas adalah sebuah objek yang dibedakanberdasarkan keadaan yang melekat padanya dan bukan berdasarkan sifat-sifat yang dimiliki. Contoh dari objek dapat dilihat pada Gambar II.27.
Gambar II.16 Objek
b. Kelas
Sebuah objek merupakan penjabaran atau bagian dalam kelas.
Sebuah kelas menggambarkan sekumpulan objek dengan sifat yang sama (atribut), perlakuan (operasi), jenis-jenis dari relasi dan sejenisnya. Objek dalam sebuah kelas mempunyai atribut dan bentuk perlakuan yang sama.
Kebanyakan objek dibedakan dari nilai atribut-atributnya dan relasi yang spesifik ke objek yang lainnya. Akan tetapi objek dengan nilai atribut dan relasi yang sama masih mungkin ada. Pemilihan dari sebuah kelas bergantung pada lingkungan dan ruang lingkup dari sebuah aplikasi, yang bergantung pada penilaian.
Dengan mengelompokkan objek-objek dalam suatu kelas, masalah dapat digambarkan. Gambaran tersebut dapat menunjukkan kegunaan dan kemampuan UML untuk menyamaratakan dari kasus-kasus tertentu dengan kasus yang sejenis. Definisi umum seperti nama kelas dan nama atribut disimpan sekali untuk setiap kelas bukan sekali perbagian.
Operasi dapat ditulis sekali untuk tiap-tiap kelas sehingga setiap objek dalam tiap kelas itu mendapatkeuntungan dari penggunaan ulang kode-kode yang telah digunakan. Gambar dari kelas dapat dilihat pada Gambar berikut.
Gambar II.17 kelas
c. Nilai dan Atribut
Nilai adalah bagian dari data. Atribut adalah sifat-sifat dari sebuah kelas yang mendeskripsikan suatu nilai yang dimiliki oleh setiap objek dalam kelas. Suatu atribut dapat ditemukan dengan melihat kata sifat atau nilai abstraknya. Sebuah atribut harus mendeskripsikan nilai bukan objek. Tidak seperti objek, nilai
tidak memiliki identitas. Dalam notasi UML atribut ditampilkan dalam kotak kedua dari kotak kelas diagram. Tipe dan nilai default dapat mengikuti setiap atribut tersebut. Tanda titik dua (:) mendahului tipe data dalam penulisan atribut. Gambar nilai dan atribut dapat dilihat pada Gambar II.29.
Gambar II.18 Nilai dan Atribut
d. Operation and Methods
Operation adalah sebuah fungsi atau prosedur yang harus diaplikasikan pada atau oleh suatu objek dalam kelas. Setiap operasi mempunyai objek tujuan seperti sebuah argumen yang lengkap.
Perlakuan darisebuah operasi bergantung pada kelas yang dituju.
Operasi yang sama dapat diaplikasikan ke banyak kelas yang berbeda seperti sebuah aplikasi yang disebut polymorphism, yaitu operasi
yang sama mempunyai bentuk berbeda dalam kelas yangberbeda.
Method adalah implementasi dari operasi dalam suatu kelas.
II.3.2
ScriptwritingScriptwriting atau skenario merupakan urutan proses yang akan dibuat dalam game dari awal hingga akhir dalam proses pengembangan game. Scriptwriting berisi pergerakan dasar karakter, lingkungan, waktu, tindakan dan dialog. Segala sesuatu yang dibuat di dalam scriptwriting bertujuan menjelaskan apa yang akan dilihat dan didengar oleh orang yang menontonnya [15].
II.3.3
StoryboardStoryboard merupakan scriptwriting dalam bentuk gambar yang nantinya akan digunakan dalam proses pengembangan. Storyboard merupakan bentuk visual dari script. Bentuknya terlihat seperti komik, namun bisa dikatakan bahwa storyboard adalah gambaran awal dari hasil yang akan dibuat. Dalam storyboard ada beberapa hal yang perlu dibahas, antara lain: perencanaan penampakan kamera, menampilkan visual effect (VFX) dan sound effect (SFX) yang mungkin saja terjadi, pose karakter, durasi, serta scene apa saja yang akan ditampilkan dalam pembuatan game [16].