Perancangan dan Implementasi Augmented Reality pada Game AR Defense Menggunakan Goblin XNA dan ALVAR

Perancangan dan Implementasi Augmented Reality pada

Game “AR Defense” Menggunakan Goblin XNA dan ALVAR

Reza Adhitya Saputra, Imam Kuswardayan Jurusan Teknik Informatika, Fakultas Teknologi Informasi

Institut Teknologi Sepuluh Nopember Surabaya Email: azer@cs.its.ac.id, imam@its.ac.id

Abstrak

Augmented Reality adalah teknologi yang dapat digunakan untuk membuat aplikasi dimana objek virtual digabungkan ke lingkungan nyata secara real-time. Sebuah objek nyata yang berfungsi sebagai penanda digunakan untuk penentuan posisi objek maya yang ditambahkan. Tugas akhir ini bertujuan untuk membuat sebuah game strategi berjenis Tower of Defense yang menggunakan teknologi augmented reality. Dalam pembuatan game ini digunakan webcam untuk melakukan tracking kepada sejumlah penanda dan pemain akan berinteraksi dengan objek maya pada permainan dengan menggunakan penanda-penanda tersebut yang berfungsi sebagai pengendali. Dalam tugas akhir ini akan didiskusikan bagaimana mendesain aplikasi game yang mengimplementasikan game augmented reality menggunakan framework Goblin XNA dan ALVAR yang digunakan untuk marker tracking.

Kata kunci : Augmented Reality, Video Game, Goblin XNA, ALVAR

1.

Pendahuluan

Augmented Reality (AR) adalah teknologi yang Seiring dengan kemajuan teknologi dan makin meningkatnya kebutuhan manusia kepada komputer, manusia selalu berusaha untuk mencari cara untuk mempermudah interaksinya dengan komputer. Perkembangan interaksi manusia dan komputer ( Human-Computer Interaction, HCI) memunculkan suatu teknologi baru yang mengubah cara interaksi manusia dengan komputer. Teknologi ini dinamakan augmented reality, yang akan mengubah secara signifikan visualisasi komputer yang sebelumnya masih terbatas pada visualisasi 2D monitor konvensional.

Augmented Reality (AR) adalah teknologi yang menggabungkan benda maya dua dimensi dan ataupun tiga dimensi ke dalam sebuah lingkungan nyata tiga dimensi lalu memproyeksikan benda-benda maya tersebut secara real-time. Sistem ini lebih dekat kepada lingkungan nyata. Oleh karena itu unsur realitas lebih diutamakan pada sistem ini. Sistem ini berbeda dengan realitas virtual yang sepenuhnya merupakan lingkungan virtual. AR juga mengijinkan penggunanya untuk berinteraksi secara real-time dengan sistem.

AR merupakan salah satu bidang HCI yang sampai saat ini sering diteliti dan terus mengalami berbagai macam perkembangan. AR sendiri sudah merambah ke berbagai macam bidang seperti kesehatan, manufaktur, hiburan, pelatihan militer, dan tak terlepas di bidang hiburan, yaitu video game. Perkembangan teknologi video game sendiri yang sedemikian pesat telah membawa perubahan pada pengembangan video game yang ada. Dalam hal ini, video game juga dapat mengadaptasi teknologi AR. AR memungkinkan untuk membuat game dimana objek virtual disatukan ke dalam lingkungan nyata dan objek nyata dapat digunakan untuk mengedalikan objek virtual. Penggabungan benda nyata

dan maya dimungkinkan dengan teknologi tampilan yang sesuai, interaktivitas dimungkinkan melalui perangkat-perangkat input tertentu, dan integrasi yang baik memerlukan penjejakan yang efektif.

Kebanyakan video game saat ini masih didalam batas-batas dari sebuah komputer, konsol, atau perangkat genggam. Layar bertindak sebagai jendela tampilan ke dunia game virtual yang memisahkan pemain dari lingkungan fisik sekitarnya. Interaksi pemain juga dibatasi dengan menggunakan set perangkat yang relatif kecil seperti joystick. Bahkan sistem kontrol evolusioner seperi Nintendo Wii masih terbatas pada tombol pengendali dan sensor pendukung yang terbatas.Sebaliknya, AR memungkinkan menggabungkan objek dan virtual dengan menampilkan gambar atau suara virtual yang membaur dengan lingkungan nyata. Hal ini tentunya juga memungkinkan pemain untuk berinteraksi dengan objek virtual dengan memanipulasi objek fisik yang terdapat di lingkungan nyata. AR membuat lingkungan fisik menjadi bagian integral dari permainan mendukung pengalaman multiplayer, memungkinkan interaksi secara spasial, dan mempertahankan konteks dunia nyata di dalam gameplay itu sendiri. Oleh karena itu, dalam pengerjaan tugas akhir ini, akan dibahas mengenai perancangan permainan menggunakan augmented reality dengan genre permainan strategi yang berjenis tower of defense.

2.

Dasar Teori

2.1.

Augmented Reality

Augmented Reality (AR), atau yang dikenal dengan realitas tertambah, adalah teknologi yang menggabungkan benda maya dua dimensi dan ataupun tiga dimensi ke dalam sebuah lingkungan nyata tiga dimensi lalu memproyeksikan benda-benda maya tersebut dalam waktu nyata.

Benda-benda maya menampilkan informasi yang tidak dapat diterima oleh pengguna dengan inderanya sendiri. Hal ini membuat realitas tertambah sesuai sebagai alat untuk membantu persepsi dan interaksi penggunanya dengan dunia nyata. Informasi yang ditampilkan oleh benda maya membantu pengguna melaksanakan kegiatan-kegiatan dalam dunia nyata.

Ada dua definisi dari AR yang diterima secara umum, salah satunya definisi dari Ronald Azuma pada tahun 1997, Azuma mendefinisikan bahwa:

1. Menggabungkan kenyataan dan virtual 2. Interaktif secara real time

3. Tergolong kedalam lingkungan 3D

Selain itu, Paul Milgram dan Fumio Kishino mendefinisikan Milgram's Reality-Virtuality Continuum pada tahun 1994. Mereka mendeskripsikan sebuah kontinum yang membentang dari lingkungan nyata ke lingkungan virtual murni. Diantaranya terdapat Augmented Reality (lebih dekat ke lingkungan nyata) dan Augmented Virtuality (lebih dekat ke lingkungan virtual). Diagram mengenai Milgram's Reality-Virtuality Continuum dapat dilihat pada Gambar 2-1.

AR sejatinya variasi lain dari realitas virtual. Teknologi realitas virtual membenamkan pengguna secara total pada lingkungan sintetis. Ketika masuk dalam dunia buatan itu, kita tidak dapat mengenali lingkungan nyata di sekitarnya. Namun AR tidak memisahkan yang nyata dengan virtual, yang terjadi adalah penggabungan antara keduanya pada ruang yang sama.

2.2.

Tower of Defense

Tower of Defense merupakan salah satu dari subgenre Real-Time Strategy. Tujuan dari Tower of Defense adalah menghentikan musuh-musih yang melintasi map dengan membangun menara-menara penyerang. Dalam membangun menara penyerang, pemain membutuhkan biaya. Biaya pembangunan sendiri didapat dari membunuh musuh-musuh yang ada.

Gameplay dari Tower of Defense sendiri memiliki karakteristik menempatkan unit statis yang tidak dapat berpindah tempat. Unit statis ini bertujuan untuk menghancurkan musuh yang berusaha untuk menghancurkan markas milik pemain. Pemain akan kalah jika sejumlah musuh berhasil menembus pertahanan dan menghancurkan seluruh markas milik pemain. Pemain

akan memenangkan game jika seluruh musuh berhasil dihancurkan terkecuali sejumlah musuh yang berhasil lolos asal tidak melebihi jumlah batas yang ditentukan.

Beberapa jenis Tower of Defense menggunakan jalur statis dimana pergerakan musuh akan selalu mengikuti jalur yang telah ditentukan dan untuk membangun menara juga tidak boleh sembarangan namun harus diletakkan di tempat-tempat yang telah ditentukan juga. Bentuk lainnya, jalur yang ditempuh musuh selalu dinamis dan biasanya memakai pathfinding untuk mencapai tujuan yang menganggap menara penyerang adalah penghalang sehingga harus mengkalkulasi jalur yang baru. Pada jenis Tower of Defense yang kedua, tempat untuk membangun menara bisa dimana saja sesuai keinginan pemain.

2.3.

Goblin XNA

Goblin XNA adalah sebuah platform open source yang digunakan untuk 3D user interface yaitu penggunaan augmented reality. Goblin XNA memiliki Lisensi BSD yang ditulis dengan bahasa pemrograman C# di atas Microsoft XNA Game Studio 3.1.

Goblin XNA video streaming sebagai sumber masukan, kemudian aplikasi ini akan melacak dan mendeteksi marker dengan menggunakan system tracking, setelah marker dideteksi, objek-objek 3D pada permainan akan dirender diatas marker seolah-olah objek-objek tersebut menyatu dengan lingkungan nyata.

Untuk meningkatkan performa aplikasi, Goblin XNA mendukung muti-core CPU yang dapat memepercepat proses rendering. Dukukangn multi-core CPU ini menggunakan thread untuk melakukan proses marker tracking sehingga proses rendering dan marker tracking dapat dilakukan secara bersamaan. Namun ketika prosesor hanya memiliki satu core, opsi thread malah akan memperlambat jalannya aplikasi.

Sistem dari Goblin XNA adalah berupa scene graph yang mirim dengan OpenSG (http://www.opensg.org/). Scene graph merupakan serangkaian node yang berbentuk n-tree yang membentuk hirarki parent-child, dimana sebuah node dapat memliki banyak child namun hanya memiliki satu parent.

Real Environment Virtual Environment Augmented Reality Augmented Virtuality Mixed Reality

Root

Camera _{Marker Light}

Geometry Transform

Transform Geometry

Geometry Particle Sound

Gambar 2-2. Goblin XNA Scene Graph

2.4.

ALVAR

Goblin XNA sesungguhnya tidak dapat melakukan Marker Tracking yang dibutuhkan untuk implementasi augmented reality, oleh karena itu Goblin XNA menggunakan library ALVAR (A Library for Virtual and Augmented Reality) yang dikembangkan oleh VTT Techical Research Centre of Finland.

ALVAR merupakan aplikasi augmented reality yang berbasis marker, yakni membutuhkan objek nyata yang berupa penanda yang dijadikan acuan posisi bagi objek maya yang nantinya akan ditambahkan.

ALVAR Marker ini menggunakan gambar marker yang dicetak ke permukaan 2D contohnya kertas. ALVAR Marker merupakan jenis marker yang berbentuk matriks, dimana marker berjenis matriks merupakan marker yang paling mudah untuk dideteksi daripada bentuk kompleks lainnya. Marker ini terdiri atas titik-titik acuan untuk memudahkan komputasi dari pengukuran parameter-parameter yang dibutuhkan didalam pengolahan citra. Marker ini akan ditangkap oleh webcam yang nantinya akan dikenali untuk dijadikan penentuan posisi pada lingkungan nyata. Contoh dari marker ALVAR dapat dilihat pada Gambar 3-1

Salah satu dukungan dari ALVAR sendiri adalah tracking beberapa marker sekaligus, hal ini dimungkinkan karena setiap marker memiliki id yang unik antara yang satu dengan yang lain. Id yang terdapat pada tiap marker berupa integer atau string.

Untuk perhitungan transformasi yang dihasilkan oleh marker, koordinat x positif adalah menuju ke bagian kanan marker dan koordinat y positif adalah menuju ke bagian depan marker, sedangkan koordinat z positif adalah menuju ke bagian atas marker seperti yang terdapat pada Gambar 3-2.

3.

Metodologi

3.1.

Analisis Sistem

Latar permainan merupakan lingkungan nyata yang diambil melalui webcam dan objek-objek 3D

digabungkan kedalamnya. Gambar dari perangkat webcam diambil melalui Video Decoder yang telah terdapat pada framework Goblin XNA, Setelah video berhasil didapatkan, tiap-tiap frame pada video akan diproses menggunakan library ALVAR yang hasilnya diambil oleh Marker Tracker pada Goblin XNA. Untuk lebih jelasnya mengenai sistem dari aplikasi dapat dilihat pada Gambar 4-5.

Gambar 3-1. Contoh ALVAR Marker

Gambar 3-2. Koordinat Marker

Posisi dan orientasi marker akan dideteksi lewat frame-frame yang ditangkap oleh kamera. Setelah marker terdeteksi, maka akan didapatkan matriks transformasi

yang dapat digunakan untuk world transformation seluruh objek yang ada dalam permainan.

Kecerdasan buatan juga akan mempengaruhi transformasi objek, dimana objek yang memiliki kecerdasan buatan akan bergerak untuk mencari jalur solusi. Selain itu, Secara kontinu efek partikel akan terus diperbaharui dan dirender. Pada hasil akhir, seluruh objek akan ditampilkan ke layar monitor. Diagram mengenai arsitektur sistem dapat dilihat pada Gambar 4-6.

3.2.

Desain

Dalam perancangan sistem pada aplikasi ini, akan dijelaskan mengenai use case yang digunakan untuk memberikan gambaran yang lebih jelas mengenai fungsi-fungsi yang terdapat pada sistem. Pada use case diagram di sistem ini, terdapat dua aktor, yaitu pemain dan sistem. Penjelasan mengenai dua aktor akan dijaleaskan pada Tabel 3-1.

Tabel 3-1. Aktor dalam Use Case

Nama Aktor Definisi

Pemain

Orang yang berinteraksi dengan sistem, yaitu pengguna yang mengakses semua fungsi yang disediakan sistem.

Sistem

Perangkat lunak itu sendiri. Sistem akan melakukan proses-proses yang berdasarkan input dari pengguna.

Gambar 4-3 menjelaskan tentang diagram use case yang berasosiasi dengan aktor pemain.

Diagram use case pada Gambar 4-4 dilakukan oleh aktor sistem dimana diagram use case ini lebih mendetailkan cara kerja didalam sistem.

4.

Perancangan

4.1.

Perancangan Marker Tracking

Untuk desain papan permainan, akan digunakan sekumpulan marker yang berjumlah 54 (9 x 6) buah pola marker. Papan permainan ini nantinya akan ditangkap oleh kamera/webcam dan transformasi matriks dari papan ini akan menjadi acuan dari seluruh objek virtual seperti pada Gambar 4-1.

Untuk melakukan pembangunan unit atau melakukan aksi spesial, pemain akan menggunakan kartu marker yang diletakkan diatas papan permainan. Letak kartu marker harus berada di dalam papan marker karena area permainan hanya terdapat di dalam papan marker seperti pada Gambar 4-2.

Gambar 4-1. Desain Papan Permainan

Gambar 4-2. Desain Penggunaan Kartu Marker

Gambar 4-3. Use Case Aktor Pemain

Gambar 4-4. Use Case Aktor Sistem Pemain

Mengubah Posisi Marker

Membangun Unit

Pemilihan Level

Melakukan Serangan Warhead

Melakukan Upgrade Unit

Melakukan Recovery Unit

Sistem

Inisiasi Marker Tracking

Load Content Update Sistem Update Gameplay <<include>> Update AI <<include>>

Pemain Marker Kamera Pemrosesan pada Komputer Monitor Manipulasi Menangkap Gambar Video Stream Render

Gambar 4-5. Arsitektur Aplikasi

Video Decoder (Direct Show) Optical Tracking (ALVAR) Particle Effect (Goblin XNA) Marker Tracker (Goblin XNA) Game Updater

Graphics Renderer (XNA) Artificial

Intelligence

Game Object

Camera Device

Display Monitor

Gambar 4-6. Arsitektur Aplikasi Sistem

Root Node Marker Node Papan Permainan Marker Node I Unit Marker Marker Node II Unit Marker

Marker Node III Aksi Spesial Transform Node Papan Permainan Geometry Node Papan Permainan Transform Node Objek A Geometry Node Objek A Objek A Transform Node Objek B Geometry Node Objek B Objek B Transform Node Objek C Geometry Node Objek C Objek C Transform Node Parikel A Particle Node Partikel A Partikel A Dan seterusnya Dan seterusnya Light Node

Light Source Transform Node Lantai Occluder

Geometry Node Lantai Occluder

4.2.

Perancangan

Augmented Reality

Dalam perancangan Goblin XNA akan dirancang menegenai bentuk dari scene graph. Untuk perancangan scene graph pada aplikasi, root node, yaitu node yang paling atas hanya akan memiliki child-child yang berupa marker node karena seluruh objek tiga dimensi yang akan dirender berada dibawah pengaruh marker node. Gambar 4-7 adalah desain keseluruhan scene graph pada permainan.

4.3.

Perancangan Efek dan Shadow Mapping

Untuk efek partikel, mirip dengan objek geometri yaitu memiliki parent berupa particle node dan diatasnya juga terdapat transform node yang digunakan untuk melakukan translasi, skala dan rotasi pada partikel. Desain particle node dijelaskan pada Gambar 4-8.

Transform Node Partikel A

Particle Node Partikel A

Partikel A

Gambar 4-8. Scene Graph pada Objek Partikel

Untuk perancangan shadow mapping, akan dibuat suatu bidang yang mereoresentasikan lantai yang akan dipasangkan ke geometry node papan permainan. Lantai ini selanjutnya akan disebut sebagai lantai occluder. Lantai occluder ini akan diatur agar dapat menerima bayangan. Agar lantai occluder ini tidak menutupi bidang datar dari lingkungan nyata, material dari lantai occluder dibuat transparan.

Untuk masing-masing entitas, baik unit milik pemain (unit markas dan unit bertahan) dan unit musuh akan diatur agar dapat mengeluarkan bayangan yang nantinya akan ditangkap oleh lantai occluder. Ketika lantai occluder menerima bayangan sedangkan lantai occluder tampak transparan akan membuat efek seakan-akan bidang datar pada lingkungan nyata tampak terkena bayangan dari objek virtual yang dibuat.

Untuk perancangannya pada scene graph, akan dibuat satu geomerti node yang menampung objek dari lantai occluder, selanjutnya geometry node tadi akan dipasangkan ke sebuah transform node. Terakhir, transform node yang tadi akan dipasangkan ke transform node papan permainan. Untuk detail desain shadow mapping pada scene graph dapat dilihat pada Gambar 4-9.

Root Node Marker Node Papan Permainan Transform Node Papan Permainan Geometry Node Papan Permainan Transform Node Lantai Occluder Geometry Node Lantai Occluder

Gambar 4-9. Perancangan Shadow Mapping pada Scene Graph

4.4.

Perancangan Gameplay

Permainan ini memiliki misi untuk menghalangi musuh yang berusaha untuk menghancurkan markas milik musuh. Untuk mencapai tujuan tersebut, pemain bertindak sebagai pihak yang bertahan sedangkan musuh yang dikendalikan oleh komputer bertindak sebagai penyerang.

Markas milik pemain bisa saja lebih dari satu yang tergantung dari level permainan, makin tinggi level permainan yang dipilih maka markas yang harus dilindungi akan semakin banyak. Pemain akan kalah jika salah satu dari markas berhasil dihancurkan oleh musuh.

Pihak musuh yang akan menyerang markas akan muncul dari titik yang dinamakan spawn point. Jika sebuah unit musuh muncul dari spawn point, unit musuh ini akan langsung berusaha untuk mencapai markas milik pemain dan berusaha untuk menghancurkannya dengan cara melakukan ledakan bunuh diri. Untuk menghalangi pihak musuh menghancurkan markas, pemain harus menghancurkan terlebih dahulu unit musuh tersebut, yaitu dengan cara membangun unit bertahan yang akan menyerang musuh. Musuh akan hancur jika nyawa yang dimiliki mencapai nol. Selain membangun unit bertahan, markas juga dapat melakukan serangan ke unit musuh namun tingkat serangan yang dihasilkan cukup rendah sehingga dibutuhkan unit bertahan yang membantu untuk menghancurkan musuh.

Jenis unit yang terdapat pada permainan ini secara garis besar ada dua buah, yaitu unit bertahan miliki pemain dan unit penyerang milik musuh. Untuk perandangan unit dalam permainan digunakan pattern decorator, karena pattern ini dapat digunakan untuk membuat banyak jenis sub-class dengan kemampuan dan sifat yang berbeda-beda.

4.5.

Perancangan Kecerdasan Buatan

Kecerdasan buatan yang akan diimplementasikan adalah algoritma patfinding A* yang akan digunakan pada unit musuh. Dalam pengerjaan tugas akhir ini, implementasi dari A* hanya pada bidang dua dimensi, walaupun video game yang dibuat berupa tiga dimensi, sehingga unit musuh tidak dapat berjalan naik ataupun turun. Bidang permainan akan dibagi-bagi menjadi array dua dimensi. Setiap node (kotak) akan memiliki status walkable atau unwakalble, dimana walkable merupakan node kotak yang dapat dilewati dan unwalkable

merupakan node yang tidak dapat dilewati karena terdapat penghalang.

Setelah mencatat status walkable dari seluruh node, akan dicari jalur solusi dari node asal A ke node tujuan B. Setelah ditemukan, unit musuh akan berjalan sesuai dengan jalur yang dikalkulasikan tadi. Setiap berhasil melangkah ke setiap node, unit musuh akan mengecek apakah node yang harus dilewati berikutnya bisa dilewati apa tidak, hal ini dikarenakan bisa saja terdapat unit menara yang baru dibentuk sehingga jalur solusi menjadi kadaluarsa. Ketika node berikutnya tidak bisa dilewati maka unit musuh akan melakukan kalkulasi ulang pada algoritma A* yaitu dari posisi sekarang menuju ke posisi tujuan.

Dari node-node tersebut dikenal istilah open list dan closed list. Open list merupakan daftar node yang memiliki kemungkinan untuk menjadi bagian dari jalur solusi untuk langkah berikutnya ,sedangankan closed list merupakan kotak yang dianggap tidak bisa menjadi jalur solusi untuk langkah berikutnya. Contoh dari closed list adalah kotak yang telah masuk ke jalur solusi atau kotak yang berstatus unwakable.

Karena A Star merupakan algoritma heuristik, maka setiap kotak memiliki bobot biaya (F) sepeti pada Rumus 4-1. Penentuan Biaya .

F = G + H

Rumus 4-1. Penentuan Biaya

Dimana :

F adalah biaya total

G adalah biaya untuk melangkah ke kotak tersebut H adalah biaya heuristik

Untuk penentuan nilai heuristik bisa digunakan banyak metode, namun untuk implementasinya pada tugas akhir ini, biaya herusitik adalah jarak garis lurus antara titik sekarang dengan titik tujuan.

5.

Implementasi

5.1.

Implementasi Marker Tracking

Implementasi marker tracking akan diawali dengan melakukan kalibrasi perangkat kamera. Dalam proses kalibrasi, akan ditangkap lima puluh buah frame dengan memotret pola papan catur. Setelah berhasil, akan dihasilkan file kalibrasi, yaitu calib.xml. File calib.xml akan disertakan dalam aplikasi. File kalibrasi ini akan berbeda-beda untuk setiap perangkat kamera yang berlainan karena tergantung oleh kualitas dari lensa kamera. Setelah selesai melakukan konfigurasi file kalibrasi langkah terakhir adalah membuat file konfigurasi untuk mengidentifikasi ID marker yang digunakan untuk memberi perintah untuk marker tracker untuk mendeteksi pola marker yang diinginkan.

Gambar 5-1. Proses Kalibrasi Kamera

5.2.

Implementasi

Augmented Reality

Untuk implementasi awal dari Goblin XNA akan diimplementasikan tiga buah variabel utama yaitu Scene, ImarkerTracking, dan IVideoCapture. Scene menrupakan kelas utama pada Goblin XNA yang menyimpan semua scene graph berikut seluruh transformasinya. IMarkerTracker merupakan interface untuk marker tracker yang akan menggunakan ALVARMarkerTracker. Untuk IVideoCapture menggunakan DirectShowCapture.

Sebelum menggunakan Goblin XNA, diperlukan untuk mengisialisasi kelas State dari Goblin XNA dan menginstansiasi kelas Scene. Setelah menginstansiasi kelas State, dilakukan pengaturan pada ThreadOption agar proses marker tracking dilakukan pada thread yang terpisah untuk meningkatkan performa aplikasi secara signifikan.

Setelah semua konfugurasi siap, Akan diinisiasikan DirectShowCapture dan ALVARMarkerTracker. DirectShowCapture digunakan untuk menangkap masukan video dan mendefinisikan berapa frame-rate maksimal dan resolusi dari video yang harus ditangkap oleh kamera. Untuk pengaturan frame-rate dan resolusi akan sangat bergantung kepada kualitas kamera, karena jika pengaturan frame-rate atau resolusi terlalu tinggi dari keampuan kamera, maka aplikasi akan error. Selanjutkan akan diinisiasikan ALVARMarkerTracker untuk melakukan marker tracking dari video yang ditangkap oleh DirectShowCapture

5.3.

Implementasi Efek dan Shadow Mapping

Untuk menampilkan efek partikel digunakan particle effect yang dipasang pada particle node. Pertama-tama, dinisiasikan particle effect dan mengatur properti DrawOrder yang digunakan untuk urutan render semenjak particle effect adalah DrawableGameComponent yang melakukan update dan draw secara otomatis. Terakhir, particle node yang baru dibuat dipasangkan ke scene graph.

Untuk implementasi dari shadow mapping dibuat sebuah transform node yang diberi nama floorTransform lalu membuat sebuah geometry node yang bernama floorGeo. Variabel floorGeo akan akan diatur untuk menampung sebuah model geomeri berbentuk kotak yang transparan. Selanjutnya diatur agar floorGeo menjadi

objek occluder dengan perintah

floorGeo.IsOccluder = true dan dapat

menerima banyangan dengan perintah

floorGeo.Model.ReceiveShadows = true.

Terakhir, floorGeo akan dopasangkan ke floorTransform, dan floorTransform akan dipasangkan ke transGround yang merupakan transform node dari papan permainan.

6.

Uji Coba Sistem

6.1.

Uji Coba Marker Tracking

6.1.1. Uji Coba Oklusi

Untuk faktor oklusi, akan dilakukan uji coba marker tracking ketika sebagian dari marker tertutup halangan. Pada marker tunggal, walapun posisi marker mengalami kemiringan, selama keseluruhan pola marker tidak tertutup halangan apapun, marker akan terdeteksi dengan baik seperti yang tampak pada Gambar 6-1.

Gambar 6-1. Uji Coba Oklusi, Marker Tunggal Terdeteksi

Namun ketika salah satu ujung dari persegi marker tertutup, walaupun bagian lain tertangkap dengan jelas dan pola di warna putih tidak terhalang apapun marker tidak akan terdeteksi seperti yang tampak pada Gambar 6-2.

6.1.2. Uji Coba Marker

Pada Gambar 6-3, tampak sebuah marker tunggal terdeteksi., dimana posisi objek yang ditampilkan pada layar sesuai dengan posisi marker yang tertangkap kamera.

Pada marker tracking yang jika terdapat marker yang kembar seperti pada Gambar 6-4, ALVAR tidak akan dapat mendeteksi secara baik (error) karena tidak boleh ada dua atau lebih pola yang yang sama terdeteksi. Dua atau lebih pola yang sama menyebabkan tracker tidak dapat menentukan posisi pola marker tersebut, sehingga menghasilkan matriks transformasi yang kacau. Pada gambar Gambar 6-4, tampak ketika dua pola marker kembar terdeteksi, tampak objek tidak digambar tidak dengan semestinya.

Gambar 6-2. Uji Coba Oklusi, Marker Tunggal Tidak Terdeteksi

Gambar 6-3. Deteksi Pola Marker

Gambar 6-4. Kesalahan Deteksi Pola Marker Kembar

6.1.3. Uji Coba Jarak

Pada uji coba jarak, semakin dekat jarak kamera dengan marker tentunya akan mengakibatkan ukuran marker yang terdeksi semakin besar sehingga marker bisa tertangkap dengan baik. Namun ketika jarak kamera dangan marker semakin jauh maka ukuran marker yang tertangkap kamera semakin kecil sehingga pola marker menjadi kabur sehingga marker menjadi tidak terdeteksi.

Salah satu permasalahan dari jarak antara kamera dan marker adalah tingkat kefokusan dari gambar yang ditangkap. Ketika mengubah-ubah posisi kamera dengan marker, maka fokus kamera akan menjadi kabur yang menyebabkan marker tidak akan terdeteksi. Masalah ini tergantung dari kualitas kamera, jika pada perangkat kamera memiliki fitur autofocus maka hal ini tidak akan menjadi masalah.

Berikut akan diuji coba layout marker dengan jumlah marker sebanyak 54 buah. Masing-masing marker berukuran 2,1x2,1 cm dengan ukuran total layout marker

sebesar 28,8x19,2cm. Hasil uji coba dapat dilihat pada Tabel 6-1.

Tabel 6-1. Uji Coba Jarak Deteksi 54 buah Marker Jarak (meter) Hasil Marker Tracking

3 Gagal

2,5 Gagal

1,2 Terdeteksi namun terjadi

inkonsistensi transformasi matriks 1 Terdeteksi namun kurang presisi 0,6 Terdeteksi namun kurang presisi 0,5 Terdeteksi dengan baik

0,4 Terdeteksi dengan baik

6.1.4. Uji Coba Resolusi Kamera

Pada uji coba resolusi perangkat kamera, semakin besar resolusi kamera, semakin besar piksel yang ditangkap oleh kamera. Semakin banyaknya piksel pada setiap frame, maka performa dari marker tracking akan semakin berat karena jumlah piksel yang harus dicek akan semakin banyak. Pada Tabel 6-2 dapat diamati ketika diatur ke resolusi rendah maka akan terjadi peningkatan frame-rate.

Tabel 6-2. Uji Coba Resolusi Kamera Resolusi Frame Rate (per detik)

Level I Level II Level III

320x240 53 50 50

640x480 45 44 44

800x450 45 44 44

800x600 38 40 42

6.1.5. Uji Coba Fokus Kamera

Fokus kamera juga menentukan keberhasilan dari marker tracking. Jika kamera tidak fokus menangkap marker seperti yang tampak pada , akan menyebabkan pola marker menjadi kabur dan gagal dideteksi. Gambar 6-5 adalah hasil uji coba ketika fokus kamera tidak tepat yang menyebabkan pola marker menjadi kabur.

Pada uji coba ini, fokus kamera menjadi sangat penting untuk proses marker tracking sehingga sebelum menggunakan aplikasi perlu diatur fokus kamera agar penangkapan objek dapat dilakukan dengan baik. Kalau perlu, kamera yang digunakan memiliki fitur autofocus sehingga ketika jarak marker berubah-ubah, fokus kamera dapat otomatis dapat menyesuaikan.

Gambar 6-5. Kegagalan Deteksi akibat Fokus Kamera 6.1.6. Uji Coba Pencahayaan

Dalam uji coba faktor pencahayaan, dalam melakukan marker tracking, tidak dibutuhkan pencahayaan yang sangat terang. Pencahayaan yang sangat terang justu mengakibatkan pola marker yang dicetak pada bidang kertas menjadi silau sehingga tingkat kehitaman dari pola marker menjadi kabur ketika ditangkap oleh kamera. Hal ini tejadi ketika dilakukan uji coba ketika menggunakan pencahayaan lampu didalam ruangan dimana cahaya yang dihasilkan oleh lampu ruangan sangat terang. Oleh karena itu, dalam proses marker tracking, pencahayaan yang diberikan sebaiknya secukupnya saja namun tidak terlalu gelap. Pencahayaan yang secukupnya akan mengakibatkan warna hitam dari pola marker akan lebih tampak sehingga proses marker tracking akan lebih baik.

6.2.

Uji Coba Efek dan Shadow Mapping

Pada efek partikel sebagaimana padaGambar 6-6, akan diuji coba efek serangan ketika menyerang musuh, efek ledakan ketika musuh menyerang markas, efek ledakan ketika musuh hancur, dan efek dari serangan spesial.

Pada penggunaan efek partikel akan memberikan kompensasi terhadap penurunan frame-rate pada permainan. Oleh karena itu penggunaan efek partikel sebaiknya tidak terlalu sering dan tidak terlalu masif.

Pada Gambar 6-7 tampak aplikasi permainan tidak menggunakan efek shadow mapping, sedangkan pada Gambar 6-8 tampak aplikasi menggunakan efek shadow mapping. Dari hasil uji coba shadow mapping, ketika efek shadow mapping diaktifkan, akan membuat objek-objek virtual semakin realistis karena seakan-akan bidang datar (yaitu bidang meja) tampak menerima bayangan layaknya dari objek asli.

Namun tampilan visual yang menarik dari shadow mapping memberikan kompensasi penurunan performa dari aplikasi. Dari hasil uji coba ketika menggunakan tiga buah level permainan semua level memberikan penurunan frame rate ketika shadow mapping diaktifkan. Hasil uji coba dapat dilihat pada Tabel 6-3. Dari tabel tersebut dapat diketahui bahwa dengan menggunakan efek shadow mapping, frame-rate akan turun sekitar 3 – 4 fps (nilai ini didapat dengan mengurangi rataan frame-rate saat shadow mapping non-aktif dengan rataan frame-rate saat shadow mapping aktif).

Tabel 6-3. Uji Coba Penggunaan Shadow Mapping

No

Frame Rate terhadap

Shadow Mapping Non-aktif Aktif 1 33 29 2 32 29 3 34 30 4 32 30 5 32 30 6 33 29 7 32 29 8 32 30 9 33 29 10 34 30 Rataan 32.7 29.5

6.3.

Uji Coba

Thread

Sebagai catatan, uji coba dilakukan pada CPU multi-core, dengan penggunaan multi-core, aplikasi memiliki satu buah thread tambahan yang khusus untuk melakukan marker tracking. Dengan tambahan thread ini, aplikasi akan berjalan lebih lancar.

Tabel 6-4 adalah tabel hasil uji coba aplikasi tanpa menggunakan thread dan menggunakan thread. Pengujian dilakukan pada tiga tingkat level berbeda karena semakin tinggi level akan memiliki jumlah musuh dan efek partikel yang semakin banyak, sehingga pada setiap level memiliki perbedaan frame-rate. Sebagai catatan, pengujian dilakukan pada tingkat pencahayaan sedang, resolusi kamera 800x450 dan efek shadow mapping nonaktif.

Tabel 6-4. Uji Coba Thread pada Marker Tracking

No Frame Rate

Thread Non-aktif Thread Aktif

1 22 33 2 21 32 3 22 34 4 22 32 5 22 32 6 21 33 7 21 32 8 22 32 9 22 33 10 22 34 Rataan 21.7 32.7

Dari hasil uji coba pada Tabel 6-4, tampak penggunaan thread akan membuat frame-rate lebih baik (sekitar 50%) sehingga tampilan permainan akan tampak lebih lancar.

6.4.

Uji Coba Gameplay

Berikut ini uji coba untuk membangun sebuah unit dengan menggunakan sebuah kartu marker. Kartu marker diletakkan di atas papan marker (yang menjadi daerah permainan), namun ketika kartu marker diletakkan di tempat yang sudah terdapat unit atau diletakkan di luar papan marker akan mengeluarkan pesan kesalahan karena

dua kondisi tersebut merupakan kondisi yang tidak valid untuk membuat unit. Gambar 6-9 menunjukkan ketika dua kartu marker diletakkan pada papan permainan dan masih melakukan proses pembangunan yang diindikasikan dengan perhitungan waktu secara mundur. Pada Gambar 6-10 menunjukkan salah satu unit berhasil dibangun dan pada Gambar 6-11 unit yang kedua berhasil dibangun.

Pada Gambar 6-12, Gambar 6-13, dan Gambar 6-14adalah hasil uji coba dari unit markas dimana unit markas akan menyerang musuh-musuh terdekat dari posisisnya dan nyawa dari unit markas akan berkurang jika diserang.

Gambar 6-15 dan Gambar 6-16 adalah hasil uji coba dari unit musuh dimana musuh muncul dari titik asal dan berusaha untuk menuju titik tujuan yaitu markas milik pemain.

Gambar 6-6. Efek Partikel Ledakan

Gambar 6-7. Shadow Mapping Nonaktif

Gambar 6-8. Shadow Mapping Aktif

Gambar 6-9. Pembangunan Unit Bertahan (1)

Gambar 6-10. Pembangunan Unit Bertahan (2)

Gambar 6-11. Pembangunan Unit Bertahan (3)

Gambar 6-12. Unit Markas (1)

Gambar 6-13. Unit Markas (2)

Gambar 6-14. Unit Markas (3)

Gambar 6-15. Unit Musuh (1)

Untuk level, akan diuji coba bagaimana variasi tiap level yang akan berpengaruh terhadap tingkat kesulitan yang akan dihadapi oleh pemain.

Pada level I seperti yang tampak pada Gambar 6-17, jumlah portal tempat unit musuh muncul berjumlah dua buah dan markas yang harus dilindungi berjumlah satu buah.

Pada level II seperti yang tampak pada Gambar 6-18, jumlah portal tempat unit musuh muncul berjumlah tiga buah dan markas yang harus dilindungi berjumlah satu buah.

Pada level III, seperti yang tampak pada Gambar 6-19, jumlah portal tempat unit musuh muncul berjumlah empat buah dan markas yang harus dilindungi berjumlah dua buah.

Gambar 6-17. Level I

Gambar 6-18. Level II

Gambar 6-19. Level III

6.5.

Uji Coba Kecerdasan Buatan

Dalam uji coba ini, akan dilakukan uji coba terhadap unit musuh dalam mencari jalur tujuan menggunakan A*. Ketika unit musuh mulai bergerak dari titik start, hal yang pertama kali dilakukan adalam mengkalkulasi jalur untuk mencapai tujuan, setelah dilakukan kalkulasi dan jalur solusi ditemukan, maka unit akan mulai untuk bergerak. Namun ketika sedang bergerak berdasarkan jalur solusi tadi unit musuh menemukan halangan baru yang sebelumnya tidak ada, maka unit musuh akan melakukan kalkulasi ulang dan segera mengubah jalur pergerakannya. Hasil uji coba A* dapat dilihat pada Gambar 6-20, Gambar 6-21, dan Gambar 6-22.

Dari hasil uji coba, tampak algoritma A* cukup berpengaruh terhadap tingkat frame-rate pada permainan, namun tidka signifikan dikarenakan walaupun jumlah unit musuh yang muncul sangat banyak , penurunan frame-rate tidak terlalu banyak.

Dalam menghitung collision detection pada setiap unit musuh, unit musuh lainnya tidak akan dianggap sebagai halangan dan bisa saja saling bertabrakan, hal ini ditujukan karena jika setiap unit musuh dianggap sebagai halangan maka kalkulasi akan menjadi jauh lebih berat dan mengganggu performa aplikasi.

Gambar 6-20. Uji Coba A* (1)

Gambar 6-22. Uji Coba A* (3)

7.

Kesimpulan

Dari hasil pengamatan selama proses perancangan, implementasi dan uji coba perangkat lunak yang dilakukan, dapat diambil kesimpulan sebagai berikut :

1. Proses marker tracking pada aplikasi telah dapat berjalan dengan baik, yaitu berhasil melakukan tracking terhadap marker-marker yang terdapat pada permainan.

2. Penggunaan thread dalam proses marker tracking dapat meningkatkan performa aplikasi sebanyak 50%.

3. Pemanfaatan augmented reality pada aplikasi permainan ini dapat berjalan dengan baik sesuai dengan perancangan, yaitu telah dapat menggabungkan objek virtual dengan lingkungan nyata secara real-time.

4. Implementasi gameplay dapat berjalan sesuai dengan skenario yang dirancang.

5. Pengunaan shadow mapping dan efek partikel telah dapat diterapkan pada aplikasi walaupun memiliki konsekuensi penurunan performa aplikasi sebesar 3-4 fps.

6. Implementasi kecerdasan buatan menggunakan algoritma A* telah diterapkan dengan baik untuk pencarian jalur solusi pada permainan AR Defense.

8.

Daftar Pustaka

[1] Wikipedia, 2010, Augmented Reality, [online], (http://en.wikipedia.org/wiki/Augmented_reality, diakses tanggal 28 Agustus 2010)

[2] Columbia University, 2009, Goblin XNA: A Platform for 3D AR and VR Research and Education, [online],

(http://graphics.cs.columbia.edu/projects/goblin/, diakses tanggal 28 Agustus 2010)

[3] Oda, Ohan., 2010, Goblin XNA, [online],

(http://goblinxna.codeplex.com/, diakses tanggal 28 Agustus 2010)

[4] VTT Technical Research Centre, 2009, ALVAR, [online],(http://virtual.vtt.fi/virtual/proj2/multimedi a/alvar.html, diakses tanggal 8 Oktober 2010)

[5] Foster, Garret., 2003, Understanding and Implementing Scene Graphs, [online],

(http://www.gamedev.net/reference/articles/article2 028.asp, diakses tanggal 11 November 2010) [6] Wikipedia, 2010, Tower of Defense, [online],

(http://en.wikipedia.org/wiki/Tower_defense, diakses tanggal 11 November 2010)

[7] Lester, Patrick., A* Pathfinding for Beginners, [online],

(http://www.gamedev.net/reference/articles/article2 003.asp, diakses tanggal 11 November 2010) [8] Ang, David., 2010, Mini Tower Defense using

Steering Behavior and A Star, [online],

(http://www.programmingmind.com/mini-tower-defense-using-steering-behavior-and-star, diakses tanggal 10 November 2010)

[9] Ohan Oda, Steven Feiner, "Interference Avoidance in Multi-User Hand-Held Augmented Reality", ISMAR '09, Florida Orlando USA, pp. 13 - 22, 2009.

[10] Ohan Oda, Levi Lister, Sean White, Steven Feiner, "Developing an Augmented Reality Racing Game", INTETAIN '08, Cancun, Mexico, 2008.

[11] Grootjans, Riemer. 2009. “XNA 3.0 Game Programming Recipes: A Problem-Solution Approach”. Apress

[12] Microsoft, 2010, App Hub – content

catalog,[online] , (http://create.msdn.com/en-US/education/catalog/, diakses tanggal 16 Desember 2010)