• Tidak ada hasil yang ditemukan

BAB 2 LANDASAN TEORI Teori Umum Software Engineering (SE)

N/A
N/A
Protected

Academic year: 2021

Membagikan "BAB 2 LANDASAN TEORI Teori Umum Software Engineering (SE)"

Copied!
46
0
0

Teks penuh

(1)

7 2.1. Teori Umum

2.1.1 Software Engineering (SE)

Software adalah program komputer dan dokumentasi asosiasi yang biasanya digunakan oleh user atau diperjual-belikan ke pasar umum. Software, Engineering adalah sebuah prinsip teknis yang mengedepankan setiap aspek perkembangan software mulai dari tahap awal sistem spesifikasi hingga perawatan jika diperlukan (Sommerville, 2011).

Pendekatan sistem yang digunakan dalam SE bisa juga dipanggil sebagai proses software, yang berarti sebuah sekumpulan aksi yang mengarah ke produksi produk software (Sommerville, 2011). Terdapat empat aktivitas mendasar dalam pengembangan software, yaitu:

1. Software specification, customers dan engineers bersama-sama mendefinisikan software yang akan dibuat beserta hambatan pada proses tersebut.

2. Software development, software didesain dan diprogram.

3. Software validation, software dites dan dipastikan sesuai dengan permintaan user.

4. Software evolution, software dibuat dan dimodifikasi untuk memenuhi permintaan user dan pangsa pasar.

2.1.2 Agile Method

Menurut Sommerville (2011), metode agile merupakan sebuah pengembangan software yang menitikberatkan pada software itu sendiri dibandingkan dengan desain dan dokumentasi. Pada umumnya, bergantung pada pendekatan bertahap untuk spesifikasi, pengembangan dan penyampaian software. Metode ini paling cocok bagi pengembangan software yang dimana spesifikasi program bisa berubah-ubah dalam waktu yang singkat.

(2)

1. Customer involvement, users harus ikut peran dalan pengembangan dan juga dalam menentukan spesifikasi dari sistem.

2. Incremental delivery, software dikembangkan dengan tambahan dari spesifikasi dan tuntutan users.

3. People not process, software dikembangkan lebih ke arah kemampuan tim pengembang itu sendiri dimana setiap orang memiliki kemampuannya tersendiri untuk bekerja tanpa harus memikirkan proses prescriptive.

4. Embrace change, software dikembangkan dengan menduga system requirements untuk berubah agar sistem pembuatan desain dapat diadaptasi berdasarkan perubahan yang terjadi. 5. Maintain simplicity, berfokus dalam kesederhanaan program

dalam arti program tersebut mudah dimengerti, baik pada software yang sedang dikembangkan atau pada proses pengembangan software.

Metode Agile membutuhkan pendekatan yang berbeda untuk manajemen proyek, yaitu beradaptasi pada pengembangan iteratif dan berfokus pada keunggulan dari metode agile. Salah satu pendekatan dalam metode agile adalah Scrum. Scrum merupakan sebuah pendekatan metode agile yang berfokus dalam menangani pengembangan iteratif dibanding dengan pendekatan teknis yang spesifik (Sommerville, 2011).

Terdapat tiga tahap dalam Scrum, yaitu: fase pertama, Outline Planning and Architectural Design merupakan tahap dimana dilakukan penentuan tujuan utama dari proyek dan mendesain arsitektur software. Tahap berikutnya merupakan Sprint Cycle, dimana pada setiap siklus dikembangkan tahapan iteratif baru dari sistem. Tahap terakhir adalah Project Closure, yang merupakan tahap dimana proyek dirapikan, penulisan dokumentasi yang dibutuhkan seperti petunjuk bagi user, dan mengevaluasi pelajaran-pelajaran yang didapat dari pelaksanaan proyek (Sommerville, 2011).

Fitur inovatif dari Scrum adalah pada tahap keduanya, atau tahap Sprint Cycle dimana dilakukan siklus sprint secara berulang-ulang

(3)

(Sommerville, 2011). Sprint pada Scrum adalah sebuah proses perencanaan yang dibagi menjadi empat tahapan, yaitu:

1. Assess, dimana pekerjaan yang akan dilakukan dapat diperhitungkan.

2. Select, dimana pemilihan dari fitur-fitur yang akan dikembangkan.

3. Develop, dimana fitur-fitur yang telah dipilih mulai dikembangkan dan dilakukan implementasi software.

4. Review, dimana pada akhir dari sprint, produk yang dihasilkan akan diberikan pada stakeholder untuk kemudian dievaluasi. Berdasarkan Sommerville (2011), karakteristik utama dari proses sprint pada Scrum adalah:

1. Jangka waktu dari setiap sprint sudah ditentukan, umumnya adalah dua sampai empat minggu.

2. Titik awal dari perencanaan adalah product backlog, yaitu daftar dari pekerjaan yang harus dilakukan pada proyek. Pada tahap assess dari sprint, backlog tersebut dicek kembali, dan dilakukan penentuan prioritas serta resiko untuk setiap pekerjaan. Konsumen sangat berperan pada proses ini dan dapat memberikan requirement atau task baru pada setiap awal siklus sprint.

3. Tahap select mengikutsertakan seluruh anggota tim proyek untuk bekerjasama dengan konsumen dalam memilih fitur-fitur dan fungsi yang akan dikembangkan pada tiap siklus sprint. 4. Ketika poin-poin diatas sudah selesai dilakukan, tim mulai

mengembangkan software sesuai kriteria. Diadakan rapat singkat yang dilaksanakan secara harian untuk mengevaluasi hasil kerja dan jika diperlukan, dilakukan juga penyusunan ulang prioritas. Pada tahap ini, tim diisolasikan dari konsumen dan seluruh komunikasi dilakukan melalui perantara berupa Scrum master. Peran dari seorang Scrum master adalah melindungi tim dari gangguan luar yang dapat menghambat kemajuan proyek. Metode dimana seorang Scrum master

(4)

melaksanakan tugasnya tergantung dari permasalahan dan keadaan tim.

5. Pada akhir siklus sprint, pekerjaan yang sudah dilakukan dievaluasi dan dipresentasikan ke stakeholder. Kemudian jika diperlukan, siklus sprint berikutnya akan dimulai.

Keunggulan dari Scrum adalah:

• Produk akhir dibagi menjadi pecahan yang mudah dimengerti dan mudah diatur.

Requirement yang tidak stabil tidak akan menghambat kemajuan proyek.

• Seluruh tim memiliki kekuasaan dan jangkauan atas seluruhnya, sehingga komunikasi antar tim akan berkembang.

• Konsumen dapat menerima laporan dan produk secara bertahap pada waktu yang ditentukan.

• Kepercayaan antara konsumen dan pengembang meningkat, juga dapat menciptakan keyakinan dimana seluruh peserta yang terlibat dalam proyek yakin akan kesuksesan proyek.

Gambar 2.1 The Scrum process (Sommerville, 2011)

2.1.3 Interaksi Manusia dan Komputer (IMK)

Untuk mengetahui apa yang harus ditampilkan di layar output dan bagaimana menginterpretasi input dari user, maka para ahli komputer bekerja dengan menggunakan interaksi manusia dan

(5)

komputer untuk mengetahui apa yang diinginkan dan memprediksi kebiasaan atau sifat dari user (Norman, 2008).

User interface (UI) merupakan bagian dari IMK yang berupa beberapa gabungan dari elemen grafis dan sistem navigasinya (Vaughan, 2011). Dalam membuat sebuah UI yang baik harus memperhatikan kualitas yang diberikan, dimana kualitas itu tersendiri memiliki kegunaan yang bersifat universal dan bermanfaat. UI yang telah dibuat akan diuji ke dalam komunitas user, yang kemudian akan digunakan sebagai alat ukur kegunaan dari UI yang dibuat.

Menurut Shneiderman & Plaisant (2010), dalam proses pengujian terdapat lima faktor manusia terukur untuk mencapai kegunaan yang diharapkan, antara lain adalah:

1. Time to learn, merupakan waktu yang dibutuhkan oleh user dalam sebuah komunitas untuk mempelajari aksi-aksi yang bersangkutan dengan tugas.

2. Speed of performance, merupakan waktu yang dibutuhkan untuk menyelesaikan tugas yang diberikan.

3. Rate of errors by users, merupakan jumlah dan jenis error yang dilakukan oleh user dalam menyelesaikan tugas, dimana error handling juga merupakan komponen penting yang harus diukur. 4. Retention over time, merupakan kemampuan user dalam

mengingat materi yang telah dipelajari, hal ini berkaitan dengan time to learn, dan frekuensi pembelajaran materi sangat penting dalam hal ini.

5. Subjective satisfication, merupakan tingkat kepuasan user dalam menggunakan aspek yang ada dalam UI.

Menurut Shneiderman & Plaisant (2010), Golden Rules merupakan delapan prinsip yang dapat diterapkan di berbagai UI secara umumnya. Aturan ini sudah diturunkan dan direvisi hampir selama 30 tahun, serta membutuhkan penyesuaian jika digunakan untuk rancangan tertentu. Delapan prinsip tersebut antara lain:

1. Strive for consistency

Konsistensi dalam UI, sebagai contoh: UI yang dibuat memerlukan alur kerja konsisten di setiap tampilan atau situasi

(6)

yang sama, terminologi yang sama juga perlu dipakai di prompts, menus dan help screens serta konsistensi warna, layout, teks, dan desain lainnya harus bisa diaplikasikan dengan baik.

2. Cater to universal usability

Desainer harus bisa menentukan dan menyadari kebutuhan dari berbagai user, memberikan fitur dimana content bisa dinikmati oleh berbagai user dari berbagai umur dan juga kemampuan penggunaan teknologi, sebagai contoh: penambahan fitur untuk pemula seperti penjelasan interface dan fitur bagi user berpengalaman seperti shortcut serta memperkaya kualitas desain.

3. Offer informative feedback

Setiap kali user melakukan suatu aksi pada UI harus ada pemberian umpan balik, sebagai contoh: munculnya message ketika user melakukan aksi.

4. Design dialog to yield closure

Alur kerja dari UI yang harus bisa dirangkai menjadi bagian pembuka, tengah dan akhir, sebagai contoh: umpan balik yang informatif setelah menyelesaikan satu rangkaian aksi dapat membuat user merasa puas karena telah mencapai akhir yang diinginkan (perasaan lega menjadi tanda agar user tidak perlu memikirkan apa yang harus dilakukan selanjutnya) dan menjadi indikator dalam mempersiapkan rangkaian kerja berikutnya. 5. Prevents error

Desainer harus dapat meminimalisir kemungkinan user untuk melakukan error. Apabila user melakukan error, maka sistem harus bisa mendeteksi error dan memberikan instruksi yang mudah dimengerti, membangun dan terarah untuk memperbaikinya, sebagai contoh: jangan biarkan user meng-input data alfabet ke dalam kolom entri numerik.

6. Permit easy reversal of actions

Desainer sebisa mungkin membuat aksi yang dilakukan user dapat dibatalkan, hal ini dapat menurunkan kepanikan user

(7)

jika melakukan error, dan fitur ini mendorong user untuk mengeksplorasi fitur-fitur lainnya yang tidak begitu familiar bagi user, sebagai contoh: pengentrian data user dapat dibatalkan, jika terjadi error.

7. Support internal locus of control

Faktor dari desain yang membuat user merasakan bahwa mereka yang memegang kendali dari UI yang diakses kemudian UI memberikan respon terhadap aksi yang dilakukan, sebagai contoh: user tidak menginginkan adanya perubahan yang mendadak atau kesulitan dalam mendapatkan suatu informasi. 8. Reduce short-term memory load

Desain yang dibuat sebaiknya tidak memerlukan banyak instruksi yang harus diingat untuk melakukan suatu rangkaian aksi terhadap UI, sebagai contoh: dalam pengisian nomor telepon, diharapkan tidak ada pengisian kembali nomor telepon yang sama.

2.1.4 Storyboard

Storyboard berguna untuk menjelaskan proyek secara detil menggunakan kata-kata dan sketsa untuk setiap gambar, suara, dan pilihan navigasi, sampai ke detil warna, isi tulisan, attributes dan fonts, bentuk tombol, styles, respon, dan voice inflections. Storyboard digunakan juga untuk menggambarkan animasi (Vaughan, 2011).

Storyboard data membantu dalam mengatur proyek dan juga membantu untuk fokus terhadap proyek secara keseluruhan. Karena dalam mendesain interaksi dan alur navigasi sering kali memerlukan perencanaan yang matang dan usaha pemrograman yang rumit, sehingga storyboard yang dibuat harus menjelaskan secara detil bukan hanya mengenai gambar dari setiap rancangan layar, tetapi juga elemen interaktif yang ada didalamnya (Vaughan, 2011).

Storyboard mirip seperti sebuah komik yang berurutan, dimana terdapat tiga sampai empat panel yang menunjukan perkembangan dari cerita atau informasi setiap harinya. Kemudian barulah dibuat strukturnya dengan merencanakan gambarannya secara berurutan

(8)

yang berisi tentang kamera, scene, sudut pandang, pencahayaan, aksi, efek, dan bagaimana object bergerak dari awal sampai akhir (Vaughan, 2011).

2.1.5 Sistem File-Based

Sistem file-based adalah koleksi dari program aplikasi yang bekerja untuk user, dimana setiap program mengatur datanya masing-masing (Connoly & Begg, 2005).

Extensible Markup Language (XML) adalah salah satu meta-language (digunakan untuk menjelaskan bahasa lain) untuk mempermudah desainer dalam membuat tag kustomisasi yang tidak tersedia pada Hypertext Markup Language (HTML). XML telah menjadi standar de facto untuk data komunikasi di dalam industri software. Beberapa analis mempercayai bahwa XML dapat menjadi bahasa yang digunakan dalam dokumen secara luas, baik online maupun offline (Connoly & Begg, 2005).

Menurut Connoly & Begg (2005), keuntungan dari XML adalah sebagai berikut:

1. Simplicity, XML memiliki standar yang sederhana. XML didesain sebagai text-based language.

2. Open standard and platform/vendor-independent, XML tidak terikat dengan platform atau vendor tertentu. XML juga berdasarkan ISO 10646, standar untuk karakter unicode dan memiliki dukungan yang sudah terintegrasi untuk teks di semua jenis alfabet, termasuk metode untuk mengetahui jenis bahasa dan encoding yang digunakan.

3. Extensibility, XML mudah dikembangkan, memberikan fasilitas kepada user untuk mendefinisikan tag sesuai keperluannya.

4. Reuse, karena mudah dikembangkan, Library XML

menfasilitasi user dengan kemudahan untuk hanya satu kali di built dan dipakai berulang-ulang.

5. Separation of content and presentation, XML memisahkan isi dari dokumen dengan presentasi datanya. Hal ini mengfasilitasi kustomisasi tampilan data.

(9)

6. Improved load balancing, dikomputasi dari proses server dan kemudian digunakan untuk meningkatkan load balancing. 7. Support for the integration of data from multiple sources, XML

mendukung proses kombinasi dari berbagai sumber dengan lebih mudah.

8. Ability to describe data from a wide variety of application, XML dapat digunakan untuk mendeskripsikan data dari berbagai variasi aplikasi. Selain itu, XML membuat data self-describing, data dapat diperoleh dan diproses tanpa memerlukan deskripsi dari data itu sendiri.

9. More advanced search engines, search engine dapat

memperingkas deskripsi dari tag yang terkait dengan XML. 10. New opportunities, salah satu kelebihan dari XML adalah

banyaknya kesempatan yang diberikan.

System catalog atau kamus data adalah tempat yang menyimpan deskripsi dari data-data yang dipakai. kamus data ini terpisah dari program aplikasi, sama seperti pendekatan pengembangan software modern dimana deskripsi internal objek dan deskripsi eksternal tersedia (Connoly & Begg, 2005). Secara umum, kamus data digunakan untuk menyimpan:

a. Nama, tipe, dan ukuran dari data. b. Nama dari relasi yang ada. c. Integritas dari batasan data.

d. Nama dari user yang mempunyai hak akses.

e. Kumpulan dari data-data yang bisa di akses oleh user dan tipe aksesnya.

f. Skema internal, eksternal, dan konseptual dan pemetaan antar skema.

g. Statistik penggunaan.

Menurut Connoly & Begg (2005), terdapat beberapa kegunaan penting dari kamus data, antara lain adalah:

1. Informasi tentang data bisa dikumpulkan dan disimpan secara terpusat.

(10)

2. Data dapat diartikan sebagai media untuk membantu user lain untuk mengerti kegunaan data.

3. Mempermudah komunikasi, karena deskripsi data tersimpan. 4. Redundansi data dan data yang tidak konsisten bisa dikenal

lebih mudah karena data sudah terpusat. 5. Perubahan terhadap data dapat tersimpan.

Dampak dari perubahan dapat diprediksi sebelum diimplementasi karena kamus data menyimpan setiap data, termasuk relasi dan user (Connoly & Begg, 2005).

2.1.6 Unified Modeling Language

Unified Modeling Language (UML) adalah penggabungan dari beberapa metode pengembangan yang object-oriented dengan tujuan untuk menciptakan sebuah proses standard dalam pengembangan sistem object-oriented. UML tidak menyediakan metode dalam pengembangan sistem, namun hanya sebuah notasi yang secara luas diterima sebagai standard dalam modeling object (Whitten & Bentley, 2007).

Menurut Whitten & Bentley (2007), UML sudah mencapai versi 2.2 dan memiliki 14 tipe diagram yang dibagi menjadi dua kategori. Tujuh tipe diagram merepresentasikan informasi structure dan tujuh lainnya merepresentasikan behavior. Berikut gambaran hirarki dari pengkategorian diagram:

(11)

Gambar 2.2 UML Superstructure Specification Version 2.2 (Object Management Group Inc., 2009)

Diagram yang digunakan dalam pengembangan penelitian ini adalah Use-Case Diagram, Use-Case Narrative, Activity Diagram dan Class Diagram.

2.1.6.1. Use Case Diagram

Menurut Whitten & Bentley (2007), use case diagram adalah sebuah diagram yang menggambarkan interaksi antara sistem internal dan sistem eksternal dan user. Use case diagram mendeskripsikan secara grafis siapa yang akan menggunakan sistem dan dengan cara apa user diharapkan akan berinteraksi dengan sistem. Use case diagram terdiri dari gabungan komponen berupa use case, actor (user), dan hubungannya. Diagram ini mengkomunikasikan cakupan high-level dari proses bisnis yang harus diproses oleh sistem. Contoh dari use case diagram:

(12)

Gambar 2.3 Use Case Diagram (Whitten & Bentley, 2007)

Use case adalah sebuah langkah-langkah yang terurut dengan tujuan untuk menyelesaikan sebuah task bisnis. Use case mendeskripsikan kegunaan sistem dari sudut pandang user eksternal dan dengan cara yang dimengerti user tersebut. Use case direpresentasikan secara grafik oleh sebuah elips horizontal dengan nama dari use case tersebut terletak di atas, bawah, atau di dalam elips. Sebuah use case menggambarkan satu tujuan dari sistem dan mendeskripsikan urutan aktivitas dan interaksi user dalam mencoba mencapai tujuan tersebut. Use case pada umumnya dianggap sebagai teknik untuk mengerti dan mendokumentasi system requirements (Whitten & Bentley, 2007).

Menurut Whitten & Bentley (2007), actor adalah sebutan untuk user eksternal yang menginisialisasi sebuah use case. Sebuah actor menjalankan sebuah use case dengan tujuan untuk menyelesaikan sebuah task bisnis. Terdapat empat jenis actor, yaitu:

(13)

1. Primary business actor, seorang stakeholder yang mendapat manfaat secara langsung dari hasil eksekusi sebuah use case.

2. Primary system actor, seorang stakeholder yang secara langsung berhubungan dengan sistem untuk menginisiasikan sebuah bisnis event.

3. External server actor, seorang stakeholder yang merespon sebuah request dari use case.

4. External receiver actor, seorang stakeholder yang bukan seorang primary actor namun mendapatkan suatu keuntungan dari sebuah use case.

Stakeholder adalah segala individu atau pihak yang memiliki minat pada suatu sistem informasi. Stakeholder dapat berupa pekerja teknis maupun non-teknis, dan dapat juga berupa pekerja internal dan eksternal (Whitten & Bentley, 2007).

Menurut Whitten & Bentley (2007), relationship adalah sebuah garis antara dua simbol dalam sebuah use case diagram yang menandakan beberapa makna tergantung dari bagaimana garis tersebut digambarkan dan tipe apa simbol yang dikoneksikan oleh garis tersebut. Berikut jenis-jenis dari relationship yang ditemukan pada use case diagram:

1. Association, sebuah relationship antara actor dan sebuah use case yang terbentuk karena interaksi antara kedua komponen tersebut.

Gambar 2.4 Representasi association pada use case diagram (Whitten & Bentley, 2007)

(14)

2. Extends, sebuah use case dapat berisi sebuah fungsi kompleks yang terdiri dari beberapa langkah sehingga sulit dimengerti. Untuk mempersingkat use case tersebut dan membuatnya lebih mudah dimengerti, use case tersebut dapat dipecah menjadi use case tersendiri yang saling berhubungan. Relationship yang menghubungkan antar use case disebut dengan extends. Extends disimbolkan sebagai panah yang menunjuk pada use case yang di-extends.

Gambar 2.5 Representasi extends pada use case diagram (Whitten & Bentley, 2007)

3. Uses/Includes, pada umumnya dapat terjadi kasus dimana dua atau lebih use case yang melakukan fungsi yang sama. Fungsi-fungsi yang sama dan redundan tersebut dapat dibentuk kedalam use case sendiri yang disebut sebagai abstract use case. Relationship antara use case dengan abstract use case disebut sebagai uses/includes yang disimbolkan dengan panah yang menunjuk ke abstract use case.

(15)

Gambar 2.6 Representasi uses/includes pada use case diagram (Whitten & Bentley, 2007)

4. Depends on, terkadang terdapat kasus dimana sebuah use

case tidak sebaiknya dijalankan sebelum actor

menjalankan use case lainnya. Dalam use case diagram, relationship tersebut disebut sebagai depends on yang disimbolkan sebagai panah yang menunjuk pada use case yang menjadi persyaratan.

Gambar 2.7 Representasi depends on pada use case diagram (Whitten & Bentley, 2007)

5. Inheritance, ketika dua atau lebih actor memiliki sifat yang serupa dan dapat mengeksekusi use case yang sama,

(16)

maka lebih baik sifat yang sama tersebut dibuat menjadi sebuah actor baru untuk mengurangi redudansi dalam komunikasi dengan sistem. Relationship antara actor baru tersebut disebut dengan inheritance (pewarisan) dimana actor yang mendapat pewarisan dari actor tersebut dapat mengeksekusi segala use case yang dapat dilakukannya. Inheritance dalam use case diagram disimbolkan sebagai tanda panah yang berasal dari actor yang diwariskan dan menunjuk ke actor yang mewariskan.

Gambar 2.8 Representasi inheritance pada use case diagram (Whitten & Bentley, 2007)

2.1.6.2. Use Case Narrative

Menurut Whitten & Bentley (2007), setelah use case diagram selesai dibuat, langkah berikutnya adalah membuat use case narrative. Use case narrative adalah deskripsi dari sebuah event dan bagaimana user akan berinteraksi dengan sistem dalam event tersebut untuk menyelesaikan suatu tugas. Berikut contoh dari sebuah use case narrative:

(17)

Gambar 2.9 Use Case Narrative (Whitten & Bentley, 2007)

Berdasarkan gambar 2.9, terdapat beberapa notasi-notasi sebagai berikut:

1. Author, nama dari seorang individu atau lebih yang berkontribusi dalam menulis use case narrative tersebut. 2. Date, tanggal dimana use case tersebut terakhir kali dibuat

atau direvisi.

3. Version, versi terkini dari use case tersebut.

4. Use case name, nama dari use case yang

merepresentasikan tujuan yang ingin dicapai oleh use case tersebut.

5. Use case type, dalam melakukan perancangan use case, umumnya yang dikembangkan pertama kali adalah business requirements use case yang fokus pada tujuan dari para stakeholder. Use case tipe ini lebih berorientasi pada bisnis dan mencerminkan tujuan yang diinginkan dari sistem.

6. Use case ID, sebuah tanda pengenal unik yang

(18)

7. Priority, melambangkan tingkat kepentingan sebuah use case dalam skala high, medium, atau low.

8. Source, menampilkan sebuah entitas yang menjalankan use case tersebut. Source dapat berupa requirement, dokumen, atau stakeholder.

9. Primary business actor, seorang stakeholder yang keuntungan utamanya berasal dari eksekusi use case tersebut.

10. Other participating actor, actor lain yang berpartisipasi dalam use case untuk mencapai tujuan use case tersebut, termasuk juga actor yang menjalankan use case dan server/receiver actor.

11. Interested stakeholder(s), berisi setiap stakeholder selain actor yang telah berinvestasi dan memiliki kepentingan atas tujuan dari use-case tersebut.

12. Description, sebuah deskripsi singkat yang berisi tujuan dari use case dan aktivitasnya.

(19)

Gambar 2.10 Use Case Narrative Expanded (Whitten & Bentley, 2007)

Untuk setiap use case narrative, terdapat versi expanded yang berisi notasi-notasi tambahan seperti pada gambar 2.10, di antaranya adalah:

1. Precondition, sebuah persyaratan yang harus dipenuhi sebelum sebuah use case dapat dijalankan. Umumnya merupakan use case lain yang harus dijalankan terlebih dahulu.

(20)

2. Trigger, sebuah event yang menyebabkan dijalankannya sebuah use case. Trigger umumnya berupa aksi fisik, atau dapat juga berupa faktor waktu (time).

3. Typical couse of events, alur aktivitas yang dilakukan actor dan sistem dalam rangka mencapai tujuan dari sebuah use case. Hal ini termasuk interaksi antara sistem dan actor dan juga aktivitas yang dilakukan sistem sebagai respon dari interaksi tersebut.

Gambar 2.11 Use Case Narrative Expanded lanjutan (Whitten & Bentley, 2007)

4. Alternate courses, berisi aksi yang dilakukan apabila terjadi suatu kejanggalan atau variasi pada use case yang berbeda dari kejadian pada umummnya.

5. Conclusion, mendeskripsikan kapan sebuah use case berakhir.

(21)

6. Postcondition, sebuah kondisi atau persyaratan yang harus dilakukan oleh sistem apabila use case tersebut telah selesai dijalankan.

7. Business rules, peraturan atau prosedur bisnis yang harus diikuti oleh sistem.

8. Implementation constraints and specifications, segala requirement yang dapat menyebabkan terhambatnya proses sebuah use case apabila tidak dipenuhi.

9. Assumption, segala asumsi yang dibuat oleh author ketika mendokumentasikan sebuah use case.

10. Open issues, segala pertanyaan atau isu yang harus diselesaikan atau diinvestigasikan sebelum use case dapat difinalisasi.

2.1.6.3. Activity Diagram

Menurut Whitten & Bentley (2007), activity diagram adalah diagram yang digunakan untuk membuat model proses atau aktivitas (activity) dari sebuah sistem. Activity diagram memiliki persamaan dengan flowchart dimana mereka menggambarkan alur activity dari proses bisnis atau use case secara berurutan. Perbedaan utamanya dengan flowchart adalah sebuah activity diagram dapat menggambarkan activities yang berjalan secara paralel. Berikut contoh dari sebuah activity diagram:

(22)

Gambar 2.12 Activity Diagram (Whitten & Bentley, 2007)

Berdasarkan gambar 2.12 diatas, activity diagram memiliki beberapa notasi-notasi sebagai berikut:

1. Initial node, sebuah simbol lingkaran yang

merepresentasikan awal dari sebuah proses.

2. Actions, sebuah persegi panjang yang merepresentasikan langkah individual dalam sebuah activity diagram.

(23)

3. Flow, panah pada diagram yang mengindikasikan sebuah proses menuju ke actions.

4. Decision, sebuah simbol belah ketupat yang memiliki satu flow input dan dua flow output. Digunakan untuk menandakan kondisi dalam activity diagram.

5. Merge, sebuah simbol belah ketupat yang serupa dengan decision, namun memiliki dua flow input dan satu flow output. Digunakan untuk menggabungkan dua buah flow menjadi satu flow.

6. Fork, sebuah persegi hitam yang memiliki satu flow input dan dua atau lebih flow output. Digunakan untuk memecah sebuah flow menjadi lebih dari satu flow paralel. Actions yang terdapat di bawah fork dapat dieksekusi secara paralel dalam urutan apapun.

7. Join, sebuah persegi hitam yang memiliki dua atau lebih flow input dan satu flow output yang menandakan berakhirnya proses paralel. Seluruh actions yang menuju ke join harus diselesaikan terlebih dahulu sebelum dapat dilanjutkan setelah melewati join.

8. Activity final, sebuah lingkaran padat di dalam lingkaran kosong yang merepresentasikan akhir dari sebuah proses. 2.1.6.4. Class Diagram

Class diagram adalah sebuah gambaran struktur object dari sebuah sistem yang menampilkan class yang menyusun sistem tersebut dan juga hubungan antara class tersebut (Whitten & Bentley, 2007). Berikut contoh dari sebuah class diagram:

(24)

Gambar 2.13 Class Diagram (Whitten & Bentley, 2007)

Berdasarkan gambar 2.13, terdapat beberapa notasi-notasi yang diantaranya adalah:

Object, sesuatu yang ada, dapat dilihat, atau dirasakan dan merupakan kumpulan dari attribute dan behavior.

Attribute, data yang merepresentasikan karakteristik dari sebuah object.

(25)

Behavior, segala sesuatu yang dapat dilakukan oleh suatu object. Dalam konsep object-oriented, behavior umumnya juga disebut sebagai method, operation, atau service. Class, sebuah kumpulan object yang saling memiliki

attribute dan behavior yang sama.

Generalization/specialization, sebuah teknik dimana attribute dan behavior yang sama dari beberapa class dikelompokkan menjadi sebuah class tersendiri yang disebut sebagai supertype. Attribute dan behavior dari supertype tersebut kemudian diwariskan pada class lain yang disebut sebagai subtype. Dalam class diagram, generalization/specialization disimbolkan dengan tanda panah kosong yang menunjuk ke supertype. Berikut contoh dari penerapan generalization/specialization:

(26)

Gambar 2.14 Representasi Generalization/Specialization pada Class Diagram (Whitten & Bentley, 2007)

Class relationship, sebuah hubungan yang ada antara satu atau lebih class pada class diagram.

Association, sebuah class relationship yang digambarkan sebagai sebuah garis yang menghubungkan sebuah class dengan class yang lain.

Multiplicity, jumlah minimum dan maksimum dari object suatu class untuk setiap object dari class lain yang berasosiasi dengannya. Multiplicity memiliki beberapa jenis yang dapat dilihat pada Gambar 2.15 berikut:

(27)

Gambar 2.15 Tipe-tipe Multiplicity dalam Class Diagram (Whitten & Bentley, 2007)

Aggregation, sebuah class relationship dimana satu class dapat terdiri dari beberapa class kecil lainnya. Digambarkan dengan simbol diamond kosong. Berikut contoh dari aggregation pada class diagram:

(28)

Gambar 2.16 Representasi Aggregation pada Class Diagram (Whitten & Bentley, 2007)

Composition, sebuah aggregation dimana suatu class berperan dan bertanggung jawab atas terbentuk dan hancurnya class-class kecil yang menyusun class tersebut. Jika class tersebut dihancurkan, maka setiap class yang membentuknya juga mengalami hal yang sama. Digambarkan dengan simbol diamond berisi. Berikut contoh dari composition pada class diagram:

(29)

Gambar 2.17 Representasi Composition pada Class Diagram (Whitten & Bentley, 2007)

Message, komunikasi yang terjadi ketika sebuah object memanggil method/behavior dari object lainnya untuk meminta informasi atau aksi tertentu. Digambarkan dengan sebuah panah yang dilengkapi dengan nama behavior yang di-request beserta segala kriteria yang dibutuhkan oleh behavior tersebut agar dapat dijalankan. Berikut contoh dari penerapan message pada class diagram:

(30)

Gambar 2.18 Representasi Message pada Class Diagram (Whitten & Bentley, 2007)

2.2. Teori Khusus 2.2.1. Game

Game pada umumnya merupakan salah satu aktivitas yang dikemas dalam bentuk yang menyerupai realita, di mana player berusaha untuk mencapai setidaknya suatu tujuan dengan bertindak mengikuti aturan yang ada. Video game adalah bentuk game yang menggunakan komputer sebagai perantaranya, dimana video game merupakan bagian dari game itu sendiri (Adams, 2010).

Menurut Adams (2010), terdapat empat komponen utama dari sebuah game, antara lain:

1. Core Mechanic.

Model yang digunakan desainer game untuk mengubah aturan umum menjadi simbol dan rumusan matematika yang dapat diimplementasikan secara algoritma. Dalam core mechanic mengandung data dan algoritma yang akan mendefinisikan aturan-aturan dalam game dan operasi internal dalam sebuah game yang akan mempengaruhi gameplay.

Terdapat beberapa komponen dalam core mechanics yang dapat menjelaskan bagaimana game yang dibuat berjalan dengan lancar, komponen tersebut antara lain:

(31)

Resources, mengarah kepada tipe object atau materi dari game yang dapat dijalankan atau berinteraksi, dimana game akan mengatur operasi secara perhitungan aritmatik untuk mengubah nilai dari komponen.

Entities, merupakan sebuah bentuk dari elemen yang ada dalam game world. Perbedaan antara resource dengan entity adalah resource merupakan tipe dari benda sedangkan entity adalah benda nyata. Entities terdapat dalam banyak jenis antara lain:

o Simple Entities, dimana entity hanya menyimpan satu attribute, contohnya seperti score atau state pada lampu merah.

o Compound Entities, dimana entity dapat menyimpan banyak attributes, contohnya seperti avatar dalam sebuah game yang menggunakan banyak attributes. o Unique Entities, dimana hanya terdapat satu entity dari

setiap jenis entity dalam game world, contohnya dalam permainan sepakbola hanya ada satu bola yang dimainkan.

Attributes, berada di dalam entity yang digunakan untuk mendeskripsikan entity tersebut atau entity lainnya.

Mechanics, dokumentasi bagaimana game world dan hal yang berada di dalamnya berinteraksi. Mechanics akan mengatur relasi antar entities, events dan proses-proses yang mengambil tempat di dalam resources dan entities di dalam game dan juga kondisi yang dapat memunculkan event dan proses-proses.

Relasi antara core mechanics dan game engine sangatlah dekat, karena core mechanics yang akan menentukan apakah game dapat berjalan dengan lancar. Dalam mereferensikan core mechanics yang hanya terdapat dalam dokumen desain, algoritma core mechanics tersebut tidak akan berarti apa-apa, tetapi jika programmer mengubah algoritma itu menjadi codes, tentunya akan menjadi sesuatu yang berguna (Adams, 2010).

(32)

Dalam permainan, core mechanics beroperasi di belakang layar untuk menbuat dan mengatur gameplay dari player, mengendalikan semua yang terjadi dalam game world, dan bekerja dengan storytelling engine untuk membantu dalam menyampaikan cerita. Storytelling engine bekerja untuk mengatur narrative events ke dalam sebuah game (Adams, 2010). Detil daftar yang dilakukan oleh core mechanics, antara lain:

Mengoperasikan ekonomi internal dalam game. Core mechanics menspesifikasi bagaimana game atau player dalam membuat, menyalurkan, dan menggunakan barang yang ada dalam game world sebagai ekonomi dalam game. • Menyediakan tantangan aktif kepada player lewat UI,

sebagaimana telah dispesifikasi dalam level design. • Menerima aksi dari player dari UI dan

mengimplementasikan efek dari aksi tersebut ke game world dan player lain.

• Mendeteksi kondisi menang atau kalah, dan kondisi lainnya yang dapat mengakhiri game.

Mengoperasikan Artificial Intelligence dari karakter non-player dan musuh artificial.

Mengubah mode game dari mode satu ke mode yang lain. Core mechanics memantau mode gameplay yang sedang aktif dan juga terjadi perubahan mode game, core mechanic akan mengubah mode dan memberi sinyal ke UI untuk mengubah menjadi UI yang sesuai.

Mengantar triggers menuju storytelling engine ketika ada game events atau aksi dari player yang mempengaruhi alur. 2. User Interface (UI).

Bagian yang menjembatani antara core mechanic dengan player. UI bukan hanya sekedar tampilan output atau menerima input, tetapi juga menggambarkan cerita dari game dan mensimulasikan keadaan dari game world.

(33)

3. Interaction Models

Salah satu model untuk menjembatani input player dengan aksi yang akan dilakukan dalam sebuah game. Model ini akan menentukan apa yang diinginkan oleh player, apa yang ingin dipilih oleh player, dan apa yang diperintahkan oleh player dalam game.

Interaction Models terbagi menjadi beberapa tipe yang secara umum sudah dikenal sebagai:

Avatar-Based, aksi player terutama dalam menggerakkan sebuah karakter individu dalam sebuah game world. Multipresent atau Omnipresent, dimana player dapat

menjalankan beberapa aksi yang berbeda dalam game world secara cepat.

party-based, dimana grup kecil dari beberapa karakter secara umum tetap bersama dalam satu kelompok yang sama.

Contestant model, model menyerupai acara kuis dimana player harus menjawab pertanyaan dan membuat keputusan.

Desktop model, menyerupai desktop atau bisa jadi desktop nyata, biasa ditemukan dalam game yang bertemakan perkantoran, seperti business simulation.

4. Camera Models

Model yang merepresentasikan model tampilan yang ingin ditampilkan oleh desainer game kepada player dalam game tersebut. Camera model muncul dalam bentuk statis dan dinamis. Model statis adalah tampilan yang diberikan adalah tampilan dengan prespektif yang sudah tetap, sedangkan model dinamis adalah tampilan game yang dapat diubah perspektifnya sesuai dengan aksi player atau event dalam game, hal ini dapat mengakibatkan permainan menjadi lebih menarik walaupun membutuhkan usaha yang lebih dalam hal desain dan implementasi.

(34)

Camera model digunakan untuk mengatur rancangan layar game yang akan ditampilkan, jenis-jenis camera model yang dipakai dalam sebuah game antara lain:

First-Person Perspective, dimana posisi kamera diset permanen di bagian mata avatar, dan biasanya player tidak dapat melihat bagian badan dari avatar, melainkan bagian tangan dapat terlihat dalam bentuk aksi ataupun dalam penggunaan senjata.

Third-Person Perspective, dimana camera ini ditemukan secara umum dalam game 3D dengan penggunaan avatar dari karakter yang lebih mendetil dan kuat sehingga player dapat melihat avatar-nya dengan baik.

Gameplay adalah perpaduan dari konsep tantangan dan aksi dimana secara spesifik, gameplay merupakan aksi yang dapat dilakukan player untuk menyelesaikan tantangan yang harus dihadapi untuk mencapai sebuah tujuan dari sebuah game. Gameplay merupakan inti dari game karena dengan memadukan tantangan dan aksi yang bertujuan untuk memenuhi kepuasan player (Adams, 2010).

Game World adalah alam semesta buatan yang dibuat di dalam sebuah game, sebuah tempat khayalan dimana menjadi tempat terjadinya sebuah event dalam game terjadi. Ketika player masuk ke dalam magic circle dan berpura-pura berada di suatu tempat, kemudian game world adalah tempat tujuannya. Magic circle merupakan pembatas yang membagi antara ide dan aktivitas yang berarti di dalam game dengan aktivitas yang ada di dalam dunia nyata, dengan kata lain bisa juga dibilang sebagai pembatas antara dunia nyata dengan dunia khayalan (Adams, 2010).

2.2.1.1 Games Genre

Games genre akan membantu player dalam

menentukan jenis-jenis game yang dimainkan dan game retails untuk mengelompokkan game tersebut. Gameplay dapat menentukan games genre (Adams, 2010).

(35)

Beberapa games genre yang dikenal adalah Action Games, Strategy Games, Role-Playing Games, Sports Games, Vehicle Simulations, Construction and Management Simulations, Adventure Games, Artificial Life and Puzzle Games, dan Online Gaming (Adams, 2010).

Action game adalah genre dari sebuah game dimana tantangan utama yang disediakan merupakan tes/ujian terhadap kemampuan fisik dan koordinasi dari player. Puzzle-solving, tactical conflict, dan eksplorasi merupakan tantangan yang juga sering ditampilkan (Adams, 2010).

Adventure game adalah cerita interaktif tentang karakter protagonis yang dimainkan oleh player. Storytelling dan eksplorasi adalah elemen esensial dari game ini. Puzzle solving dan tantangan yang konseptual mempunyai pengaruh besar terhadap gameplay. Combat, economic management dan action merupakan tantangan yang jarang dan mungkin tidak ada (Adams, 2010).

Action-Adventure adalah genre hibrida dari action games dan adventure games, dimana memiliki frekuensi yang lebih cepat dari adventure games dan memasukkan kemampuan fisik sebagai tantangan utama, sehingga dalam bermain, player membutuhkan kemampuan fisik yang memadai, dan dalam game juga terdapat storyline, berbagai karakter lainnya, sistem inventori, dialog dan fitur lain dari adventure games (Adams, 2010).

2.2.1.2 Game Concept

Menurut Adams (2010), Game concept adalah sebuah rincian mendetil dari sebuah game yang memiliki potensi menjadi produk komersial. Game concept setidaknya harus memiliki beberapa poin-poin dibawah ini:

• Pernyataan dari konsep, berisi dua sampai tiga kata yang bisa mendeskripsikan game yang dibuat.

(36)

Sebuah mode gameplay utama, mencakup camera model, interaction model, dan tantangan umum yang akan dialami oleh player.

Genre dari game tersebut, jika ada perpaduan, nyatakan pula bagian mana yang merupakan perpaduannya, jika game ini merupakan game yang baru, jelaskan mengapa tidak dapat digabungkan ke dalam genre yang sudah ada. Sebuah deskripsi tentang target player dari game yang

akan dibuat.

Nama dari mesin yang akan menjalankan game dan peralatan tambahan yang diperlukan.

• Lisensi yang akan dipakai, jika dipakai. • Mode kompetisi yang ada dalam game.

Ringkasan umum tentang bagaimana game berjalan dari awal sampai selesai, termasuk beberapa ide tentang level atau misi dan sinopsis tentang alur cerita, jika ada. 2.2.1.3 Game Balancing

Menurut Adams (2010), game balancing adalah konsep yang digunakan untuk menjaga game agar tidak terlalu mudah atau terlalu sulit dimainkan. Game balancing yang baik biasanya memiliki beberapa karakteristik sebagai berikut:

Game memberikan pilihan berarti, dimana game tersebut menyediakan beberapa cara yang bisa digunakan oleh player dalam menyelesaikan tantangan.

• Keberuntungan bukan merupakan suatu faktor yang relevan, karena seorang player telah bermain untuk kurun waktu yang lama tetap akan lebih handal daripada player yang awam.

Player versus Environment (PvE) merupakan sebuah tipe game dimana player berusaha menyelesaikan tantangan yang disediakan tetapi tidak secara langsung bersaing dengan player lain (Adams, 2010).

(37)

Menurut Adams (2010), dalam game PvE game balancing setidaknya terdapat dua karakteristik:

Player dapat merasakan game yang dimainkan itu adil. Persepsi player tentang game yang adil melibatkan berbagai faktor yang rumit karena tidak adanya player lain.

Tingkat kesulitan dari game harus konsisten. Tingkat kesulitan dari game harus berada dalam batas jarak yang bisa dimaklumi agar tidak membuat player kaget dengan perubahan yang mendadak dengan meningkatnya atau menurunnya tingkat kesulitan yang tinggi.

Beberapa hal yang merupakan bagian dari beberapa pikiran player tentang game yang adil adalah:

Game harus dapat memberikan tantangan dalam tingkat kesulitan maksimum secara konsisten, dengan tidak adanya perubahan yang tiba-tiba. Player menganggap perubahan yang tiba-tiba dalam tingkat kesulitan game itu tidak adil.

• Player seharusnya tidak secara tiba-tiba kalah dalam game tanpa peringatan dan bukan karena kesalahan dari dirinya, bisa juga dibilang sebagai desain learn-by-dying, dimana pernah menjadi sistem yang umum, tetapi sekarang menjadi tidak adil, karena tetap saja kematian karakter yang berulang-ulang tetap tidak menyenangkan. Hal ini bisa dihindari dengan memberikan player peringatan akan bahaya yang akan dihadapi.

Stalemate tidak boleh terjadi, yang bisa terjadi jika dalam beberapa situasi dalam game membuat player tidak bisa menang ataupun kalah.

Game tidak boleh memberikan pilihan kepada player tanpa informasi yang memadai.

• Semua pengetahuan yang diperlukan untuk memenangkan game harus ada di dalam game. Player

(38)

seharusnya tidak perlu memerlukan penelitian tersendiri di luar dari game world untuk memenangkan game. Game seharusnya tidak membutuhkan tantangan yang

secara umum tidak diberikan dalam genre-nya, bila game yang dibuat memiliki genre yang hibrida, maka harus diberitahukan terlebih dahulu sebelum player mulai bermain.

2.2.1.4 Level Design

Level design merupakan proses dalam membangun pengalaman yang akan diberikan secara langsung kepada player, menggunakan komponen yang disediakan oleh desainer game (Adams, 2010). Desainer Level membuat beberapa bagian yang esensial untuk pengalaman bagi player, antara lain:

Ruang dimana game itu berada. Ketika desainer game menentukan object/benda apa saja yang akan ada dalam game world, desainer level menentukan fitur apa saja yang akan ada di setiap level dalam game world dan dimana saja fitur ini akan diberikan. Desainer level akan mengambil rencana dari desainer game dan membuat game lebih spesifik dan konkret.

Kondisi awal dari level, termasuk dari kondisi berbagai fitur yang dapat berubah-ubah, banyaknya musuh artificial yang akan dihadapi player, banyaknya resources yang akan diatur oleh player di awal permainan, dan lokasi dari resources yang dapat ditemukan dalam bidang.

• Tantangan-tantangan yang akan dihadapi oleh player di setiap level-nya. Banyak game yang menyediakan tantangan dalam alur yang linier, jika seperti itu, desainer level menentukan urutan dari tantangan tersebut, membangun ruang yang sesuai, dan memberikan tantangan sebagai bumbu tambahan di dalamnya.

(39)

Kondisi yang dapat mengakhiri level tertentu biasanya dikenal dengan kondisi menang atau kalah.

Hubungan yang saling mempengaruhi antara gameplay dengan cerita dari game, jika ada. Penulis cerita harus bekerjasama dengan desainer level agar terjalin hubungan yang baik antar gameplay dengan event narrative.

Estetika dan pengaturan alur di setiap level-nya, desainer level akan menentukan implementasi model dan tekstur untuk menentukan suasana hati dalam game yang dibuat.

Menurut Adams (2010), beberapa prinsip level design pada umumnya terdiri atas:

Buatlah level awal sebagai level tutorial. Variasikan frekuensi game di tiap levelnya.

• Ketika player melewati tantangan yang membutuhkan resources player, sediakan resources yang lain.

• Hindari konsep yang tidak masuk akal.

• Perjelas himbauan kepada player tentang tujuan terdekat yang harus dicapai.

• Informasi tentang resiko, hadiah, dan akibat dari pilihan yang dibuat harus jelas.

• Berikan hadiah kepada player atas kemampuan, imaginasi, kepintaran, dan dedikasi.

• Berikan hadiah dalam banyak bentuk/cara dan berikan kemungkinan untuk mendapat hukuman sekecil mungkin.

• Latar depan lebih diutamakan daripada latar belakang. • Tujuan dari musuh artificial adalah untuk memberikan

perlawanan yang cukup menantang.

• Implementasikan variasi tingkat kesulitan jika memungkinkan.

(40)

2.2.1.5 Game Engine

Game engine merupakan bagian dari software yang mengimplementasikan aturan game. Pembuatan sebuah prototype hendaknya menggunakan game engine, sehingga game dapat dibuat dengan mudah dengan fitur yang disediakan oleh game engine tersebut, salah satunya dapat diartikan untuk mempermudah pembuatan object yang digunakan dalam game (Adams, 2010).

Banyak sekali game engine yang telah beredar disaat ini, salah satunya adalah: Unity yang merupakan game engine yang mendukung pengembangan game 2D dan 3D dalam berbagai platform. Unity dikembangkan oleh Unity Technologies, pada saat ini telah mendukung beberapa platform seperti, Windows, Mac, Linux, Unity web player, iOS, Android, BlackBerry 10, Windows Phone 8, Xbox 360, dan PS3. Game engine ini memiliki versi gratis dan UnityPro yang berbayar, para developer tetap dapat mempublikasikan game-nya di kedua versi ini, perbedaanya terdapat dari fitur-fitur yang diberikan dimana versi UnityPro memiliki fitur-fitur yang lebih baik. (Unity Technologies, 2013)

2.2.1.6 Game Design Document

Seorang desainer game perlu membuat kumpulan dokumen-dokumen untuk memberitahukan kepada orang lain tentang desain game yang telah direncanakan. Biasanya dokumen tersebut berbeda maksudnya bagi para desainer maupun programmer, namun hal tersebut terikat oleh rangkaian umum. Hal ini memungkinkan para desainer dan programmer bekerja sama untuk mencapai tujuan yang sama. Bagian terpenting pada desain game adalah dengan mewariskan desain yang telah dirancang kepada anggota tim. Untuk itu, diperlukan adanya dokumen yang telah

(41)

dirancang sedemikian rupa agar serupa dengan rancangan desain yang diinginkan (Adams, 2010).

Terdapat beberapa tipe dari dokumen desain game yang digunakan secara umum (Adams, 2010). Beberapa tipe tersebut adalah:

1. High Concept Document

Dokumen ini bukan bertujuan untuk membangun struktur game, melainkan hanya memperlihatkan tujuan dari ide game yang dirancang sedemikian rupa. Penulisan dokumen ini tidak boleh lebih dari 4 halaman. Hal ini berguna untuk menyimpan ide yang mungkin akan digunakan pada kedepannya.

2. Game Treatment Document

Dokumen ini menyajikan game dalam sebuah garis besar kepada orang yang telah berminat dan berkeinginan untuk mengetahui lebih lanjut. Mirip dengan High Concept Document, dimana tujuan utama dokumen ini dirancang demi memberikan informasi lebih lanjut tentang game yang sedang dirancang. Oleh karena itu, dokumen ini tidak wajib dibuat dalam rancangan game.

3. Character Design Document

Dokumen ini dibuat bertujuan untuk menyimpan rancangan desain dari karakter-karakter yang akan digunakan dalam game. Tujuan utama dari game ini digunakan untuk memperlihatkan tampilan dari karakter dan daftar animasi bagaimana karakter itu bergerak.

4. World Design Document

Dokumen ini merupakan basis dari segala rancangan lingkungan game yang dibuat dan musik yang akan digunakan. Data disini tidak harus sama persis dengan yang berada dalam game, tetapi

(42)

setidaknya memberikan informasi secara garis besar apa yang terdapat dalam dunia game.

5. Flowboard

Dokumen ini merupakan gabungan dari flowchart dan storyboard. Sesuai dengan namanya, dokumen ini digunakan untuk menggabungkan kedua ide tersebut untuk membentuk sebuah struktur dalam game.

6. Story and Level Progression Document

Dokumen ini menyimpan segala jenis story yang dibuat dalam game beserta dengan perkembangan level dari satu ke yang selanjutnya. Jika game yang dibuat tidak mempunyai cerita atau hanya memiliki satu jenis level, dokumen ini tidak perlu dibuat.

7. The Game Script

Dokumen ini bertujuan untuk memperlihatkan seluruh isi naskah dari game yang dirancang. Dokumen ini merupakan sebuah bagian penting yang tidak mencakup dokumen dan mekanika inti dari game. Dokumen ini tidak termasuk dengan desain teknis, walaupun dokumen ini memerlukan spesifikasi minimum secara teknis.

2.2.2. Multimedia

Multimedia adalah sebuah kombinasi dari lima elemen utama (Vaughan, 2011). Lima elemen tersebut adalah:

1. Teks

Setiap penggunaan kata memiliki banyak arti yang berbeda, maka sangat penting keakuratan pada setiap kata yang dipilih. Dalam multimedia, kata-kata ini biasanya akan digunakan pada judul, menu, navigasi pembantu, dan juga isi. Kata dan simbol dalam bentuk apapun, tertulis maupun terucap merupakan sistem komunikasi secara umumnya. Oleh karena itu, teks merupakan salah satu elemen penting dalam multimedia.

(43)

2. Gambar

Elemen gambar dapat diubah menjadi ukuran, warna, dan pola yang berbeda-beda, dan juga dapat dibuat transparan untuk diletakkan di depan atau dibelakang objek lain. Elemen gambar dapat dihasilkan oleh komputer dalam dua cara, sebagai bitmap/raster dan vector. Bitmap lebih digunakan sebagai gambar foto realistik, sedangkan Vector lebih digunakan untuk garis, kotak, lingkaran, poligon, dan berbagai jenis bentuk lainnya. Gambar dalam multimedia digunakan untuk menarik perhatian user.

3. Audio

Audio merupakan sebuah elemen multimedia yang paling sensual. Ketika sesuatu bergetar di udara bergerak maju dan mundur, hal tersebut membuat gelombang tekanan. Ketika gelombang tersebut mencapai gendang telinga, getaran atau tekanan akan berubah menjadi suara yang akan didengar.

4. Animasi

Animasi merupakan sebuah sumber utama dari aksi dinamik dalam representasi multimedia. Animasi membuat sebuah gambar statis menjadi hidup, dalam artian membuat sebuah gambar bergerak dan terus berubah menjadi gambar-gambar lainnya yang berhubungan.

5. Video

Video merupakan sebuah elemen yang digunakan untuk memperkuat multimedia, serta membuat user merasa lebih dekat pada dunia nyata. Dari semua elemen multimedia, video memerlukan performa terbesar dari komputer atau alat bantu yang digunakan pada aspek memori.

2.2.3. Virtual Reality

Virtual Reality (VR) adalah istilah yang mendeskripsikan sebuah simulasi yang menciptakan gambaran dari sebuah dunia yang diterima oleh indera manusia dalam cara yang sama dengan persepsi seperti dunia nyata (Craig, Sherman, & Will, 2009).

(44)

Head-Mounted Display adalah sebuah alat yang dapat digunakan dalam aplikasi Virtual Reality (VR) atau Augmented Reality (AR) agar user dapat melihat informasi meskipun user menggerakkan kepalanya. Tergantung dari HMD yang digunakan, user juga dapat memanfaatkan arah pandang kepala mereka untuk menangkap informasi jika HMD tersebut dilengkapi dengan sensor pendeteksi gerakan kepala. Model-model yang berbeda juga menyediakan spesifikasi yang berbeda, antara lain seperti audio support, resolusi layar, jangkauan dari field of view (FOV) dan lainnya (Shneiderman & Plaisant, 2010).

Oculus Rift adalah sebuah perangkat HMD yang ditujukan pada masyarakat luas dengan harga komersil. Perangkat tersebut dikembangkan oleh Oculus VR. Oculus Rift memiliki beberapa fitur pendukung seperti FOV atau jarak pandang yang luas, display dengan resolusi tinggi, dan memiliki teknologi untuk melacak gerakan kepala dengan latency yang rendah, sehingga user dapat menikmati visual dalam game secara leluasa. Umumnya HMD memiliki latency tinggi yang menyebabkan gerakan tidak akan terbaca secara lancar/smooth, karena itu teknologi yang digunakan Oculus Rift mengubah pandangan developer mengenai HMD. Saat ini Oculus Rift masih dalam tahap pengembangan dan belum dirilis secara komersil. Teknologinya yang unik mendapat dukungan penuh dari beberapa developer ternama seperti Epic Games dan Valve (Oculus VR, 2012). 2.2.4. Kinect

Three Dimensional Input Devices adalah sebuah perangkat yang mengirim tiga isi data spasial secara simultan, device ini masih jarang dikembangkan tetapi penggunaan motion-sensing devices mulai diterapkan dalam industri game (Adams, 2010).

Motion-sensitivities gaming devices adalah sebuah perangkat yang menggunakan kemampuan accelerometers dalam menghitung tiga dimensi spasial sehingga dapat mendeteksi pergerakan di semua arah. Accelerometers adalah perangkat elektronik yang mencatat kecepatan yang dialami (Adams, 2010).

(45)

Kinect atau awalnya dikenal dengan sebutan "Project Natal" adalah sebuah perangkat input yang dapat mengubah cara bermain dari game dimana player tidak memerlukan sebuah controller untuk memainkan game. Kinect menerapkan teknologi motion detection yang dapat menangkap setiap gerakan player dan mengubahnya menjadi informasi yang dapat ditangkap oleh game (Microsoft, 2009). Selain menangkap informasi gerakan, Kinect juga dapat mengenali dan merespon perintah suara dari player. Perintah suara tersebut dapat digunakan untuk fungsi-fungsi di luar dari bermain game, seperti memberhentikan tayangan film (Microsoft, 2013).

Kinect awalnya dirilis eksklusif untuk konsol Xbox 360, namun Microsoft merilis Kinect untuk PC dengan nama "Kinect for Windows 1.0" pada tanggal 1 Februari 2012 (Kinect for Windows Team, 2012).

2.3. State of the Art

Kinect merupakan salah satu perangkat yang mendukung full-body play dan memiliki fitur voice recognition. Ketika direlease terdapat tiga perangkat yang inovatif di dalam sensor Kinect, yaitu Color VGA video camera, Depth Sensor, dan Multi-array Microphone (Crawford, 2011).

Sampai dengan Februari 2013, penjualan Kinect terjual sebanyak lima juta perangkat dihitung dari bulan Mei 2012. Jika dijumlahkan, penjualan dari awal dirilis pada tahun 2010 sampai sekarang, Kinect sudah terjual sebanyak 24 juta perangkat (Makuch, 2013).

Oculus Rift merupakan salah satu Head-Mounted Device yang dikembangkan untuk gaming yang lebih immersive. Perkembangan terkini tentang Oculus Rift yang dipamerkan di PAX Australia 2013, sudah tersedia versi Oculus Rift yang mendukung resolusi 1080p, lebih baru daripada versi developer kit yang hanya mendukung resolusi 720p (Garreffa, 2013).

Kemudian untuk menambah minat user terhadap Oculus Rift, Oculus VR bekerja sama dengan IndieCade untuk membuat kompetisi VR-Jam 2013 yang diikuti lebih dari 220 tim dan 1000 aplikasi virtual reality (Oculus VR, 2013). Selain PC, Oculus Rift juga akan mengadakan pengembangan untuk aplikasi berbasis mobile (Gilbert, 2013).

(46)

Gambar

Gambar 2.1 The Scrum process (Sommerville, 2011)
Gambar 2.2 UML Superstructure Specification Version 2.2  (Object Management Group Inc., 2009)
Gambar 2.3 Use Case Diagram (Whitten & Bentley, 2007)
Gambar 2.4 Representasi association pada use case diagram  (Whitten & Bentley, 2007)
+7

Referensi

Dokumen terkait

(3) Apabila hasil pemeriksaan sebagaimana yang dimaksud ayat (1) pasal ini ternyata menimbulkan gangguan yang membahayakan lingkungan, kepada perusahaan tersebut

Pemerintah Kabupaten Aceh Utara melalui Badan Perencanaan Daerah (Bappeda), merencanakan hingga tahun 2020 lahan yang akan dan dapat dikembangkan untuk irigasi teknis dengan

Penelitian ini bertujuan untuk membuat penjadualan perkuliahan dengan metode integer linear programming. Penjadualan perkuliahan ini menggunakan pendekatan action research

Pada penelitian Arief (2013) telah dilakukan perhitungan untuk jarak dari bottom bracket hingga headset ) dan jarak dari headset hingga pangkal rear fork ). Perhitungan tersebut

Hasil penelitian menunjukkan bahwa hasil nilai korelasi hasil ρ : 0,652, dengan tingkat signifikasi 0,000 berarti terdapat hubungan antara minat masuk jurusan

Informasi dalam dokumen ini didasarkan pada pengetahuan terkini kami dan berlaku untuk produk yang berkaitan dengan tindakan pencegahan dan keselamatan. Itu tidak mewakili

Target penerimaan perpajakan pada APBN tahun 2013 ditetapkan sebesar Rp1.193,0 triliun, terdiri atas pendapatan pajak dalam negeri sebesar Rp1.134,3 triliun

MySQL Cluster adalah database dengan high availability dan high scalability dimana menggunakan arsitektur data storage shared-nothing dan antarmuka SQL yang telah