Dokumen Pengembangan Produk

Dokumen Pengembangan Produk Lab. Sistem Kendali & Komputer, STEI ITB Lembar Sampul Dokumen Dokumen ini dikendalikan penyebarannya oleh LSKK, STEI - ITB

Judul Dokumen Jenis Dokumen Nomor Dokumen Nomor Revisi Nama File Tanggal Penerbitan Unit Penerbit Jumlah Halaman

Dokumen Desain : Game “The Transporter” DSG: Desain Produk DSG01 01 B300-R1.ODT 14 Juli 2008 Game 37 (termasuk lembar sampul)

Data Pengusul Pengusul

Nama

Alfa Faridh Suni Alvani Wiwoho Harold Harriman Uray Lunar Meiviar

Tanggal

Tanda tangan

Lembaga

STEI - ITB

Alamat

Jl. Ganesha 10 Bandung

Telepon

085640845672 081321222020 08112208046 02270106525

Nomor Dokumen : DSG01

Jabatan

Faks

Nomor Revisi : 01

Email

Tanggal 05/05/08

[email protected] [email protected] [email protected] [email protected]

Halaman 1 / 37

Daftar Isi Daftar Ilustrasi......................................................................................................................................5 Sejarah revisi dokumen .......................................................................................................................6 1.Pengantar...........................................................................................................................................7 1.1 Ringkasan isi dokumen ...............................................................................................................7 1.2 Tujuan Penulisan.........................................................................................................................7 1.3 Referensi.....................................................................................................................................7 1.4 Daftar Singkatan.........................................................................................................................8 2. Hardware Design Specification ........................................................................................................9 2.1 Pendahuluan...............................................................................................................................9 2.2 Fungsi hardware........................................................................................................................9 2.3 Interface Hardware....................................................................................................................9 2.4 Kebutuhan Hardware (Hardware Requirements).....................................................................11 3. Software Design Specification ........................................................................................................12 3.1 Desain Interface Software.........................................................................................................12 3.1.1 Module Interfacing.............................................................................................................12 3.1.2 Hardware-Software Interface ...........................................................................................12 3.1.2.1 3D Graphics API..........................................................................................................12 3.1.2.2 Audio API....................................................................................................................13 3.1.2.3 Networking API..........................................................................................................13 3.1.2.4 InputDevice API.........................................................................................................14 3.1.3 UML Component Diagram.................................................................................................14 3.1.4 UML Class Diagram............................................................................................................15 3.1.4.1 Overview Class Diagram.............................................................................................15 3.1.4.2 AudioEngine Overview Class Diagram.......................................................................16 3.1.4.3 PhysicsEngine Overview Class Diagram.....................................................................21 3.1.4.4 InputEngine Overview Class Diagram.......................................................................21 3.1.4.5 NetworkEngine Overview Class Diagram..................................................................22 3.1.4.6 VisualEngine Overview Class Diagram......................................................................23 3.2 Spesifikasi Data........................................................................................................................24 3.2.1 Data Visual........................................................................................................................24 3.2.1.1 Geometry...................................................................................................................25 3.2.1.2 Texture......................................................................................................................25


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 2 / 37

3.2.1.3 Shader........................................................................................................................25 3.2.1.4 Scene Graph..............................................................................................................27 3.2.1.5 Entity Material...........................................................................................................29 3.2.2 Audio Data........................................................................................................................30 3.2.2.1 Audio Sample............................................................................................................30 3.2.2.2 Audio Effect...............................................................................................................31 3.2.2.3 Environmental data...................................................................................................31 3.2.2.4 Spatial Data...............................................................................................................32 3.2.2.5 Temporal Data..........................................................................................................32 3.2.3 Physics Data......................................................................................................................32 3.2.3.2 Physics Body.............................................................................................................32 3.2.3.2 Physics Shape............................................................................................................33 3.2.3.3 Physics Joints............................................................................................................34 3.2.3.4 Physics Environments...............................................................................................35 3.2.4 User Interface Data..........................................................................................................35 3.2.4.1 Scripts........................................................................................................................35 3.2.4.2 GUI............................................................................................................................35 3.2.4.3 Text Console.............................................................................................................35 3.2.5 Game Logic Data...............................................................................................................35 3.2.5.1 Game State................................................................................................................35 3.2.5.2 Game Event...............................................................................................................35 3.2.5.4 Game Script..............................................................................................................36 3.2.6 Networking Data..............................................................................................................36 3.2.6.1 Extrapolator..............................................................................................................36 3.2.6.2 Interpolator..............................................................................................................36 3.2.6.3 Compressor/Decompressor......................................................................................37 3.2.6.4 Protocol....................................................................................................................37 3.3 Spesifikasi Modul.....................................................................................................................37 3.3.1 Input Engine.................................................................................................................37 3.3.2 Physics Engine..............................................................................................................37 3.3.3 Graphics Engine...........................................................................................................40 3.3.4 Audio Engine...............................................................................................................42 3.3.5 Game Logics................................................................................................................44 3.3.6 Network Engine...........................................................................................................44 Nomor Dokumen : DSG01

Nomor Revisi : 01

Tanggal 05/05/08

Halaman 3 / 37

4.Lampiran .........................................................................................................................................46


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 4 / 37

Daftar Ilustrasi Illustration 1: Hardware Function : UML Deployment Diagram.......................................................................10 Illustration 2: 3D API Abstraction Layer...........................................................................................................12 Illustration 3: Audio API Abstraction Layer......................................................................................................12 Illustration 4: Winsock Abstraction Layer........................................................................................................12 Illustration 5: Game Components....................................................................................................................13 Illustration 6: Overview Class Diagram............................................................................................................14 Illustration 7: AudioEngine Overview Class Diagram.......................................................................................15 Illustration 8: PhysicsEngine Overview Class Diagram.....................................................................................15 Illustration 9: InputEngine Overview Class Diagram.......................................................................................16 Illustration 10: NetworkEngine Overview Class Diagram.................................................................................16 Illustration 11: VisualEngine Overview Class Diagram......................................................................................17 Illustration 12: Frustum...................................................................................................................................18 Illustration 13: Rendering & Shader................................................................................................................20 Illustration 14: Scene Graph............................................................................................................................21 Illustration 15: Octree......................................................................................................................................21 Illustration 16: Lighting Shader Material.........................................................................................................22 Illustration 17: Physics Collision Shape............................................................................................................25 Illustration 18: Convex Hull.............................................................................................................................26 Illustration 19: Physics Body Joint...................................................................................................................26 Illustration 20: Physics Simulations................................................................................................................30 Illustration 21: Physics Simulation Step...........................................................................................................30 Illustration 22: Collision Contact Point............................................................................................................31 Illustration 23: Object Transformation............................................................................................................32 Illustration 24: Texture Mapping....................................................................................................................32 Illustration 25: Programmable Rendering Pipeline.........................................................................................33 Illustration 26: HRTF based SOund.................................................................................................................34 Illustration 27: Dead-Reckoning......................................................................................................................36


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 5 / 37

Sejarah revisi dokumen Versi

Tanggal

01

14 Juli 2008 Tim


Oleh

Deskripsi Revisi Awal

Nomor Revisi : 01

Tanggal 05/05/08

Halaman 6 / 37

1.Pengantar 1.1 Ringkasan isi dokumen Dokumen ini berisi desain dari proyek yang akan kami kembangkan yaitu sebuah PC Game dengan judul “The Transporter”. Deskripsi serta gambaran awal mengenai game ini kami tulis pada dokumen B100 dan spesifikasi dari game kami tuliskan pada dokumen B200. Pada dokumen ini akan kami tuliskan deskripsi desain dari game ini dengan lebih detail termasuk sisi teknis dari rencana pengembangan game tersebut. Isi dokumen ini secara garis besar kami bagi dua yaitu hardware dan software, pada bagian software kami tuliskan deskripsi pembagian dari modul-modul software secara lebih lanjut, beserta fungsi dan komponen yang terkait dari setiap modul software tersebut.

1.2 Tujuan Penulisan Tujuan penulisan dari dokumen ini yaitu : 1.

Sebagai landasan dalam pelaksanaan pengembangan aplikasi game

2. Untuk memudahkan proses pengembangan aplikasi game 3. Sebagai acuan dan referensi dalam pengembangan game dan pengembangan lebih lanjut 4. Sebagai bagian dari dokumentasi proyek

1.3 Referensi Dave Shreiner, Mason Woo, Jackie Neider,OpenGL ARB . “OpenGL Programming Guide : The Official Guide to Learning OpenGL Version 2.1 6th edition”. Addison Wesley 2007 (ISBN 0321481003) Gregory Junker. “Pro OGRE 3D Programming”, Apress 2006 (ISBN 1590697109) Luke Ahearn. “3D Game Textures: Create Professional Game Art using Photoshop”, Focal Press 2006 (ISBN 0240807685) Matthew Omernick. “Creating the Art of the Game”. New Riders 2004 (ISBN 0735714096) Matt Pharr, Greg Humhreys. “Physcally Based Rendering: From Theory to Implementation”. Morgan Kaufmann. 2004 (ISBN 012553180X) Havok Physcs SDK, Telekinesys Recearch Ltd. 2007


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 7 / 37

1.4 Daftar Singkatan LSKK-ITB

Laboratorium Sistem Kendali Komputer – Institut Teknologi Bandung

LAN

Local Area Network

NPC

Non-Person Character

CV

Curriculum Vitae

SDM

Sumber Daya Manusia

GPS

Global Positioning System

FPS

First Person Shooter

AI

Artificial Inteligence

OGRE

Object oriented Graphics Rendering Engine

BSP

Binary Search Partitioning

HRTF

Head-related transfer function

GIMP

GNU Image Manipulation Program

GNU

GNU is Not Unix

RC

Release Candidate

HRTF

Head Related Transfer Function


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 8 / 37

2. Hardware Design Specification 2.1 Pendahuluan Pada pengembangan proyek ini kami tidak mengembangkan sebuah hardware khusus untuk menjalankan game ini, melainkan kami akan menggunakan hardware yang umumnya telah tersedia untuk memainkan sebuah PC based game.

2.2 Fungsi hardware Umumnya hardware yang digunakan adalah untuk pemrosesan aspek interaksi antara user dengan game sendiri, yang secara fungsi garis besar dibagi menjadi 4 bagian yaitu: fungsi input, proses, komunikasi dan output dari game. Input hardware kami akan memanfaatkan komponen input dari PC yang umumnya telah tersedia yaitu keyboard dan mouse dengan tambahan opsional kami akan mendukung penggunakan game pad untuk menjalankan game ini. Proses hardware umumnya terbagi dua yaitu CPU dan GPU, dimana CPU kami gunakan untuk melakukan proses atau komputasi logika dari game beserta perhitungan fisika dan audio yang akan dilakukan oleh physics engine dan audio engine, sedangkan GPU digunakan untuk pemrosesan bagian visual dari game ini. Output hardware terdiri dari dua bagian yaitu hardware untuk menampilkan hasil pemrosesan visual dan hardware untuk audio yaitu monitor dan speaker. Communication hardware adalah hardware yang dapat berfungsi sebagai input dan sekaligus output dari sistem game, yang kami gunakan adalah communication device atau networking device yang berguna sebagai fasilitas multiplayer dari game yang akan kami kembangkan.

2.3 Interface Hardware Berikut adalah gambaran umum bagaimana setiap hardware yang kami gunakan akan saling terinterkoneksi untuk menjalankan fungsi sebuah game, kami gambarkan dalam diagram UML: Deployment Diagram :


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 9 / 37

2.4 Kebutuhan Hardware (Hardware Requirements)

Illustration 1: Hardware Function : UML Deployment Diagram

Ada beberapa syarat tersedianya hardware yang harus dipenuhi untuk menajalankan game ini, diantaranya untuk input device, ketersediaan mouse dan keyboard harus dipenuhi, sedangkan untuk CPU disyaratkan harus dapat melakukan instruksi SSE dan SSE2, untuk GPU diperlukan minimal GPU yang mendukung sampai Shader Model 3.0, detail lebih lanjut mengenai tertulis pada dokumen B200


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 10 / 37

3. Software Design Specification 3.1 Desain Interface Software Untuk bagian software kami membagi game ini menjadi beberapa “engine”, setiap engine memiliki fungsi khusus diantaranya input engine, physics engine, graphics engine, audio engine, network engine, AI, dan game logics. Spesifikasi dan detail lebih lanjut setiap engine kami tuliskan pada bagian 3.3.

3.1.1 Module Interfacing Hubungan antara modul kami gambarkan dalam UML Component diagram pada bagian 3.1.3. Ada 4 module yang berhubungan dengan hardware, mengenai hubungan hardware-software dari modul ini kami tuliskan pada bagian 3.1.2. Komposisi dan arsitektur dari setiap modul kami tuliskan melalui UML class diagram pada bagian 3.1.4. Class Diagram pada bagian ini kami tuliskan tidak secara lengkap melainkan hanya sebagai “overview” mengenai arsitektur dari setiap engine tersebut berhubung sangat kompleksnya arsitektur dari engine tersebut apabila digambarkan secara lebih detail.

3.1.2 Hardware-Software Interface Beberapa API yang kami gunakan untuk interfacing dengan hardware diantaranya : –

OpenGL / Direct3D untuk akses pada GPU

–

OpenAL unuk akses pada SoundCard

–

Windows Socket 2.0 untuk akses pada networking subsystem di Windows

–

DirectInput untuk akses pada input devices

3.1.2.1 3D Graphics API Untuk game ini kami menggunakan graphics engine OGRE (ObjectOriented Graphics Rendering Engine) engine ini mendukung lebih dari satu render system diantaranya OpenGL dan Direct3D, sehingga game kami dapat dijalankan dengan menggunakan kedua buah API tersebut. Didalam engine OGRE terdapat submodule yang bertindak sebagai abstraction layer rendering system, sehinga aplikasi yang diatasnya akan melihat render system yang digunakan sebagai “blackbox” walaupun ada beberapa item spesifik yang hanya ada disalah satu render system tersebut. Berikut adalah abstraction layer mengenai arsitektur dari kedua buah API tersebut pada operating system Windows :


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 11 / 37

Illustration 2: 3D API Abstraction Layer

3.1.2.2 Audio API Kami menggunakan OpenAL sebagai akses pada audio hardware, openAL mendukung operasi yang “hardware accelerated” dimana seluruh proses dilakukan di hardware maupun software emulation apabila tidak terdapat hardware yang mendukung fitur tertentu. Selain OpenAL ada beberapa API lain yang dapat berjalan diatas windows diantaranya DirectSound, berikut adalah abtraction layer mengenai API tersebut :

Illustration 3: Audio API Abstraction Layer

3.1.2.3 Networking API API untuk mengakses networking pada windows kami menggunakan windows socket API 2.0, berikut adalah diagram abstraction layer dari API ini :

Illustration 4: Winsock Abstraction Layer Nomor Dokumen : DSG01

Nomor Revisi : 01

Tanggal 05/05/08

Halaman 12 / 37

3.1.2.4 InputDevice API Kami menggunakan API DirectInput untuk mendapatkan akses pada input device secara exclusive, dimana pada mode ini game mendapatkan prioritas data dari input device secara exclusive, selain itu keuntungan yang didapatkan apabila menggunakan directInput adalah aplikasi mendapatkan akses low-level pada input device untuk mengolah data input dari user, sehingga diharapkan game akan mendapatkan performa tertinggi dari input device tanpa adanya gangguan dari aplikasi lain yang secara bersamaan mendapatkan data input dari device juga.

3.1.3 UML Component Diagram

Illustration 5: Game Components


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 13 / 37

3.1.4 UML Class Diagram 3.1.4.1 Overview Class Diagram

Illustration 6: Overview Class Diagram


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 14 / 37

3.1.4.2 AudioEngine Overview Class Diagram

Illustration 7: AudioEngine Overview Class Diagram

3.1.4.3 PhysicsEngine Overview Class Diagram

Illustration 8: PhysicsEngine Overview Class Diagram Nomor Dokumen : DSG01

Nomor Revisi : 01

Tanggal 05/05/08

Halaman 15 / 37

3.1.4.4 InputEngine Overview Class Diagram

Illustration 9: InputEngine Overview Class Diagram

3.1.4.5 NetworkEngine Overview Class Diagram

Illustration 10: NetworkEngine Overview Class Diagram


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 16 / 37

3.1.4.6 VisualEngine Overview Class Diagram

Illustration 11: VisualEngine Overview Class Diagram


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 17 / 37

3.2 Spesifikasi Data 3.2.1 Data Visual Data untuk keperluan visual atau graphic terdiri dari data camera (eye), light (posisi cahaya) dan visual entity. Data dari camera (eye) digunakan untuk mentransformasikan object dalam dunia game (world space) kepada layar monitor (screen space), camera memiliki parameter near-clip, far clip, dan field of view yang akan membentuk sebuah “viewing frustum”, dan sebagai optimasi hanya objek didalam frustum ini saja yang akan dirender di layar.

Illustration 12: Frustum

Sedangkan light object memiliki parameter posisi, orientasi, direction, light power, light type, light color dan attenuation parameter, parameter cahaya ini digunakan dalam proses pencahayan dan pembentukan “shadow” pada tahap rendering. Seluruh entiti atau objek dalam game diatur dalam sebuah struktur pohon (tree data structure) untuk kemudahan proses transformasi dan “visibility culling”, struktur data ini dinamakan scene graph, dan modul yang mengolah data ini dinamakan scene manager. Setiap objek game visual umumnya memiliki data geometry yang berupa mesh, data image yang berupa tekstur dan data material yang tertulis dalam shader (instruksi rendering).

3.2.1.1 Geometry sebuah benda atau entity dalam dunia visual dibangun oleh sekumpulan vertex (titik) yang dihubungkan oleh edge, 3 atau 4 buah vertex akan membentuk face (muka) yang kemudian digabungkan akan membentuk sebuah objek, objek ini disebut dengan mesh atau model. File format mesh ada berbagai macam diantaranya .x, .3ds, .mesh dan lain-lain, dalam game ini kami akan menggunakan format .mesh


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 18 / 37

yaitu OGRE mesh format. Sebuah data mesh terdiri dari berbagai macam data diantaranya : –

posisi vertex (berisi koordinat setiap vertex dalam object space)

–

vector normal vertex (berisi vector yang menjukkan arah dari muka yang dibangun vertex)

–

vertex color (warna dari setiap vertex, digunakan untuk keperluan rendering)

–

vector tangent vertex (digunakan untuk membentuk tangent space dalam proses rendering)

–

edge list dan index (berisi data bagaimana setiap vertex terhubung dengan vertex lainnya)

–

texture coordinate (berisi koordinat texture yang digunakan dalam proses mapping)

3.2.1.2 Texture Texture adalah sebuah data image (citra) yang digunakan dalam proses rendering, sebagian besar texture digunakan untuk menambah detail dari sebuah objek (mesh) dan dapat juga digunakan sebagai informasi pada proses kalkulasi pada vertex atau pixel shader sebagai “table lookup”. Berbagai macam texture yang digunakan pada game kami adalah sebagai : –

Color Map, digunakan sebagai texture mapping pada setiap objek

–

Normal Map, digunakan untuk menghitung pencahayaan yang lebih detail pada permukaan object

–

Specular Map Texture, digunakan untuk menghitung faktor specular dalam proses pencahayaan..

–

Diffuse Map Texture, digunakan untuk menghitung factor diffuse light dalam pencahayaan.

–

CubeMap / Spherical Map Texture, digunakan untuk environmental map atau reflection dari permukaan object.

–

HeightMap, sebuah texture yang berisi nilai ketinggian dari sebuah permukaan.

–

Lightmap, sebuah texture yang berisi “pre-computed” lighting.

3.2.1.3 Shader Shader adalah sebuah data yang mengantung instruksi untuk melakukan transformasi dari geometri dan rendering geometri, shader terbagi tiga yaitu vertex shader, pixel shader dan geometry shader. Vertex shader adalah instruksi yang dilakukan pada setiap vertex, pada tahap ini umumnya dilakukan transformasi dan proses perhitungan koordinat yang melibatkan data setiap vertex, hasil dari vertex shader diproses lebih lanjut pada pixel shader. Pixel shader adalah instruksi yang dilakukan pada setiap vertex ( atau lebih tepat dikatakan pada tiap Nomor Dokumen : DSG01

Nomor Revisi : 01

Tanggal 05/05/08

Halaman 19 / 37

fragment), pada tahap ini umumnya dilakukan proses pencahayaan dari permukaan setiap object berdasar data yang didapat dari geometry, texture, hasil vertex processing dan variable lainnya yang disuplai dari program. Geometry adalah instruksi yang digunakan untuk memanipulasi geometry (vertex) pada tahap ini, program dapat melakukan penambahan dan penghapusan vertex yang tidak dapat dilakukan pada vertex processor.

Illustration 13: Rendering & Shader

3.2.1.4 Scene Graph Scene graph adalah data struktur yang berupa pohon (tree data structure) setiap setiap node dari pohon ini akan terdiri dari berbagai macam entity, dimana entity yang berada pada subnode dari node ini memiliki parameter spatial relatif terhadap parameter dari node diatasnya. Sehingga apabila sebuah node bergerak maka node dibawahnya (child node) akan ikut bergerak demikian pula apabila terjadi perubahaan orientasi. Berikut adalah contoh scene graph dari sebuah mobil di atas jalan :


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 20 / 37

Illustration 14: Scene Graph

Pada scene graph ini apabila sebuah mobil bergerak atau berganti arah maka bodi, ban dan pengendara mobil tersebut juga mengikuti pergerakan mobil, apabila pengemudi menggerakkan mobil ke kiri, maka ban akan berorientasi ke arah kiri diikuti dengan perubahan orientasi dari pelek ban (tyre rim) dan karet ban (tyre rubber) mengikuti orientasi dari node “CarTyre”. Sebuah scene graph diatur oleh modul yang dinamakan scene manager, selain scene graph berdasarkan hubungan hierarkial seperti diatas, ada pula scene graph spatial yaitu pembangunan tree berdasarkan parameter spatial benda (posisi, dimensi dan orientasi), scene graph spatial ini digunakan untuk optimasi dalam collision detection dan visibility culling yaitu metode untuk menentukan apakah suatu objek tertutup oleh objek didepannya sehingga apabila objek tersebut tertutup maka tidak diperlukan proses rendering pada objek tersebut. Salah satu implementasi dari spatial scene graph ini adalah octree yang digunakan oleh game ini :

Illustration 15: Octree Nomor Dokumen : DSG01

Nomor Revisi : 01

Tanggal 05/05/08

Halaman 21 / 37

3.2.1.5 Entity Material Setiap objek dalam dunia visual 3D harus dapat dibedakan jenisnya antara satu sama lain, untuk itu diperlukan adanya data material, data meterial visual ini selain warna atau texture dari sebuah objek, diperlukan pula data tambahan yang diperlukan untuk melakukan proses pencahayaan. Beberapa data atau faktor tambahan untuk pencahayaan ini diantaranya : –

Ambient, nilai pencahayaan uniform salah satu parameter light.

–

Diffuse, dapat menggunakan diffuse map atau dihitung secara realtime

–

Specular, dapat menggunakan specular map atau dihitung secara realtime

–

Shininess, salah satu nilai factor dalam menghitung pencahayaan specular

–

Emissive, nilai dari setiap object atau dapat menggunakan glow map

–

Reflectance, menggunakan environment mapping (cubemap, spherical map,..)

–

Transparency, dapat menggunakan channel alpha dari color texture

–

Roughness, dapat menggunakan data dari normal map texture

Illustration 16: Lighting Shader Material


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 22 / 37

3.2.2 Audio Data 3.2.2.1 Audio Sample Audio sample adalah data yang berisi informasi suara yang tertulis dalam format PCM (pulse Code Modulation) ada dua format yang kami gunakan yaitu format audio mono 16-bit dan stereo 16-bit dengan sampling rate 44.1Khz. Format audio mono kami gunakan untuk data dari sound efek sedangkan yang stereo digunakan untuk keperluan musik. Setiap audio sample akan dihubungkan pada sebuah audio source yang merupakan entity dalam dunia audio didalam game, setiap audio source dapat memiliki satu atau lebih audio sample yang digabungkan dalam sebuah track. Setiap audio source akan memiliki spatial dan temporal variable yang dapat dirubahrubah sesuai keperluan game dan dapat dihubungkan pada objek audio effect yang bertindak sebagai filtering dari suara yang akan dikeluarkan.

3.2.2.2 Audio Effect Audio effect adalah sebuah objek dalam audio engine yang terhubung dengan satu atau lebih objek audio source sebagai filtering atau pengubah suara, terdapat berbagai macam effect yang dapat digunakan dalam game sesuai dengan spesifikasi OpenAL 1.1 diantaranya: –

Reverberation

–

Chorus

–

Distortion

–

Echo

–

Flanger

–

Frequency Shifter

–

Vocal Morpher

–

Pitch Shifter

–

Ring Modulator

–

Autowah

–

Compressor

–

Equalizer

3.2.2.3 Environmental data Setiap audio source berada dalam dunia audio dan dunia audio ini sendiri memiliki beberapa parameter Nomor Dokumen : DSG01

Nomor Revisi : 01

Tanggal 05/05/08

Halaman 23 / 37

environmental yang mempengaruhi hasil akhir sifat suara yang akan dikeluarkan, beberapa parameternya diantaranya : –

Reverberation Density

–

Reverberation Diffusion

–

Reverberation Gain, Hi-Frequency Gain dan Low Frequency Gain

–

Decay Time, Decay Hi-Frequency Ratio dan Decay Low-Frequency Ratio

–

Reflection Gain dan Reflection Delay

–

Reflection Pan

–

Late Reverberation Gain dan Late Reverberation Delay

–

Late Reverberation Pan

–

Echo Time dan Echo Depth

–

Modulation Time dan Modulation Depth

–

High Frequency Reference dan Low-Frequency Reference

–

Room Rolloff Factor

–

Hi-Frequency Air Absorption Gain

–

Decay Hi-Frequency Limit

3.2.2.4 Spatial Data Data spatial dari setiap objek audio source dan listener diantaranya : –

Position

–

Orientation

Khusus untuk audio source terdapat beberapa tambahan parameter, diantaranya : –

Cone Inner Angle

–

Cone Outer Angle

–

State

–

Gain

3.2.2.5 Temporal Data Setiap audio source dan listener memiliki parameter velocitu sebagai parameter temporal, yang mempengaruhi pada doppler effect.


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 24 / 37

3.2.3 Physics Data 3.2.3.2 Physics Body Physics body adalah representasi fisika (kecuali bentuknya) dari sebuah objek physics, physics body terbagi dua macam yaitu rigid body dan soft body, rigid body adalah objek physics yang tidak dapat ber-deformasi atau berubah bentuk apabila terjadi collision berbeda dengan soft body. Dalam game ini kami hanya menggunakan rigid body untuk melakukan simulasi fisika-nya. Setiap physics body menyimpan sejumlah parameter fisika sebagai informasi bagi solver pada physics engine, diantaranya mass, inertia, center of mass, position, orientation, linear velocity, angular velocity, angular force, linear force, angular acceleration, linear acceleration, linear impulse, point impulse, angular impulse, torque, linear damping, angular damping, static friction, dynamic friction, restitution coefficient, drag coefficient, dan inertia tensor

3.2.3.2 Physics Shape Physics shape adalah representasi bentuk dari sebuah objek physics, data ini digunakan untuk collision detection, umumnya setiap entity physics adalah gabungan dari physics body yang berisi parameter fisika dari objek dan physics shape yang berisi data bentuk sesungguhnya dari objek. Physics shape dapat dibangun dari berbagai macam primitive shape seperti Box, Cylinder, Cone, Sphere dan lain-lain, setiap primitive shape dapat digabungkan untuk membentuk shape yang lebih rumit yang dinamakan compund shape. Selain shape yang dibangun dari primitive shape, adapula shape yang dibangun dari kumpulan vertex seperti halnya pada graphics engine, namun shape yang dibentuk oleh kumpulan vertex ini memiliki kompleksitas perhitungan collision yang lebih rumit dibandingkan primitive shape. Berikut adalah berbagai macam jenis physics shape :

Illustration 17: Physics Collision Shape Nomor Dokumen : DSG01

Nomor Revisi : 01

Tanggal 05/05/08

Halaman 25 / 37

Shape yang dibangun dari kumpulan vertex ada dua jenis yaitu bentuk yang convex dan concave, bentuk concave memiliki kompleksitas lebih tinggi dibandingkan bentuk convex dalam perhitungan collisionnya, sehingga dalam merepresentasikan bentuk visual yang terkadang memiliki bentuk concave dibutuhkan proses lebih lanjut (non-realtime) untuk merubah bentuk ini menjadi bentuk convex dengan cara menambahkan vertex sehingga membentuk “face” baru yang membuat bentuk benda itu menjadi convex, proses ini dinamakan “convex hull”.

Illustration 18: Convex Hull

3.2.3.3 Physics Joints Setiap dua atau lebih physics body dapat digabungkan menjadi sebuah joined body, yang menambah “constraint” dalam perhitungan simulasinya, terdapat berbagai macam bentuk joint masing-masing memiliki sifat yang berbeda-beda, sebagai contoh joint “hinge” adalah seperti hubungan pintu dengan dinding yang terkoneksi dengan sebuah engsel.

Illustration 19: Physics Body Joint

Berikut adalah detail lebih lengkap mengenai jenis-jenis physics body joint: –

Ball / Socket Joint

–

Spring Joint

–

Hinge Joint

–

Prismatic Joint

–

Angular Motor Joint


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 26 / 37

–

Linear Motor Joint

–

Slider Joint

–

Piston Joint

–

Universal Joint

3.2.3.4 Physics Environments Seluruh object physics agar dapat saling berinteraksi harus diletakkan pada sebuah environment atau world yang sama, physics world ini sendiri memiliki beberapa parameter yang mempengaruhi seluruh objek yang berada didalamnya seperti gravitasi.

3.2.4 User Interface Data 3.2.4.1 Scripts Data script ini berisi informasi mengenai deskripsi event untuk mendeskripsikan interaksi antara user dan program, setiap sebuah komponen dari user interface memiliki invoker, event dan handler, setiap handler dipetakan pada satu atau lebih event dan invoker akan melakukan “trigger” pada event dan handler function yang terhubung akan dijalankan. Script ini berisi pemetaan antara event dan handler sehingga perubahan pada logika user interface akan mudah untuk di-debug dan di modifikasi.

3.2.4.2 GUI Data GUI adalah data visual dari komponen user interface diatas, umumnya merupakan texture yang dipetakan pada sebuah quad.

3.2.4.3 Text Console selain user interface secara grafik disediakan pula interface dalam bentuk text, hal ini untuk memudahkan development interface yang sifatnya sangat teknis dan sulit untuk dibuatkan GUI-nya satu persatu.

3.2.5 Game Logic Data 3.2.5.1 Game State setiap game memiliki state-state tertentu dimana dalam setiap state memiliki fungsi yang berbeda-beda, data dari state memiliki informasi mengenai user interface, input map, event list, dan game model sendiri.


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 27 / 37

3.2.5.2 Game Event game event merupakan salah satu bagian dari game state, dimana perubahan state terjadi apabila sebuah game event terjadi. Game event ada bermacam-macam seperti physcis event salah satunya event collision, game logic event misalnya apabila pemain gagal atau berhasil menyelesaikan misi, dan lain-lain.

3.2.5.4 Game Script Setiap game state dan game event ditulis pada sebuah script yang diload pada saat runtime, sehingga memudahkan modifikasi tanpa perlu melakukan compile ulang program dari game tersebut.

3.2.6 Networking Data 3.2.6.1 Extrapolator Tujuan utama modul networking dalam game adalah untuk melakukan sinkronisasi seluruh parameter objek didalam game, namun karena keterbatasan bandwidth dan besarnya latency, diperlukan metoda untuk mengurangi efek ini, salah satunya dengan “dead-reckoning” dimana setiap partisipan dari game mengirimkan parameter temporal (kecepatan, akselerasi dan gaya fisika) dari setiap objek dengan interval yang adaptive terhadap suatu nilai threshold tertentu, kemudian parameter ini di remote participant akan digunakan sebagai parameter untuk melakukan prediksi pergerakan (extrapolasi). Setiap session game dimulai akan dibuat kesepakatan antara seluruh partisipan dalam mode multiplayer yaitu mengenai data dan model extrapolasi yang akan digunakan. Model extrapolasi ada bermacam-macam digunakan sesuai keperluan dan sifat pergerakan dari objek yang akan diprediksi, parameter dari model diantaranya terdiri dari orde prediksi yaitu menggunakan parameter kecepatan atau orde yang lebih tinggi seperti akselerasi atau gaya yang diterima objek, ataupun parameter constaint karena tidak semua objek dalam game memiliki “degree of freedom” yang sama, ada objek yang statis tidak bergerak, bergerak hanya pada arah tertentu dan memiliki cara pergerakan yang berbeda-beda, data constraint ini digunakan sebagai parameter sehingga model prediksi dapat lebih akurat memprediksi pergerakan objek tanpa memerlukan data parameter yang besar.

3.2.6.2 Interpolator Proses updating dari model “dead-reckoning” adalah diskrit dan adaptive yaitu data update diterima oleh remote partisipan hanya ketika pergerakan suatu objek diluar batas (threshold) model prediksi (keadaan dimana model prediksi memiliki error yang besar dari batas error maksimum), sehingga ada kemungkinan data update diterima hanya dengan frekuensi 2Hz (2 kali update dalam satu detik) sedangkan untuk


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 28 / 37

keperluan visual dibutuhkan setidaknya update data spatial sebanyak minimal 60Hz, untuk ini dibutuhkan metoda interpolasi antara setiap data update yang diterima. Terdapat berbagai macam model interpolasi, seperti linear, quadric, spline, dan lain-lain. Penentuan model ini dipilih oleh setiap partisipan dalam jaringan pada setiap objek tertentu, dan setiap objek memiliki model yang paling optimal atau paling cocok untuk sifat pergerakan objek tersebut.

3.2.6.3 Compressor/Decompressor Setiap paket data yang dikirimkan umumnya berisi data numeric yang bisa dikompres lebih lanjut, sehingga model kompresor dan dekompresor dalam network engine membantu meningkatakan efisiensi komunikasi antara partisipan dalam game.

3.2.6.4 Protocol Setiap aplikasi network memiliki protocol yang berbeda-beda, untuk game (termasuk game ini) akan menggunakan protocol network UDP pada jaringan multicast, protokol ini dipilih dengan menimbang faktor performa dan latency dari networkingnya, protocol UDP adalah protocol yang “lightweight” sehingga relatif lebih cepat dan memiliki besar paket dan overhead yang kecil apabila dibandingkan dengan TCP. Namun protocol TCP adalah protocol yang lebih reliable dibandingkan dengan UDP. Reliability dari protocol UDP dalam game dapat ditingkatkan dengan menggunakan pemrosesan lebih lanjut, sehingga dalam game umumnya dikenal istilah protocol Reliable-UDP, dalam network engine setiap packet diberi sequence number, checksum dan parameter lain yang digunakan untuk prosessing lebih lanjut sehingga meningkatkan reliability dari protocol UDP ini.

3.3 Spesifikasi Modul 3.3.1 Input Engine Input engine berfungsi untuk memproses input dari user melalui input device, data dari input device merupakan data “raw” yang harus diolah terlebih dahulu agar berguna untuk keperluan game, salah satu fungsi dari input engine adalah untuk memetakan antara input dan fungsi (input mapping) dalam game, contohnya adalah menentukan tombol di keyboard yang berguna untuk melakukan manuver “steering”, pemilihan menu, pengaturan view dan lain-lain.

3.3.2 Physics Engine Physics engine berfungsi untuk melakukan perhitungan fisika berdasar hukum newton terhadap bendaNomor Dokumen : DSG01

Nomor Revisi : 01

Tanggal 05/05/08

Halaman 29 / 37

benda atau objek didalam game, sehingga pergerakan atau efek dinamika dari setiap benda akan terlihat realistik, physics engine menghitung seluruh pergerakan dengan membaca berbagai macam parameter dari benda yang telah ditentukan diantaranya : masa, friksi, titik pusat masa, gravitasi, gaya, akselerasi dan lainlain. Setiap proses yang dilakukan oleh physics engine adalah menghitung pergerakan semua objek dalam game secara bertahap (time stepping) umumnya sebanyak jumlah frame grafik yang ditampilkan dalam satu detik (fps: frame per second) sehingga dibutuhkan minimal 60 kali updating physics objek dalam satu detik, setiap proses frame dari physics akan dilakukan oleh 3 sub-modul dari physics engine yaitu solver, integrator dan collision detector.

Illustration 20: Physics Simulations

Solver dari physics engine berfungsi untuk menghitung setiap perubahan yang diperlukan untuk mereduksi error yang akan terjadi pada integrator, setiap physics objek umumnya memiliki “joint” dengan objek lain dan beberapa “constraint” lainnya seperti pencegahan untuk terjadinya penetrasi pada rigid body, hasil dari proses yang dilakukan solver akan dikirimkan ke integrator.

Illustration 21: Physics Simulation Step

Pada Integrator dilakukan perhitungan (integration) untuk mendapatkan “motion state” terbaru berdasarkan parameter fisika yang dimiliki oleh setiap objek physics dan waktu yang terlewatkan dari Nomor Dokumen : DSG01

Nomor Revisi : 01

Tanggal 05/05/08

Halaman 30 / 37

update sebelumnya sebagai “delta-time” (elapsed time), proses integrasi ini mirip dengan cara menghitung nilai integral dari suatu persamaan dengan menggunakan solver numeric dengan input delta time. Collision detector berguna untuk menentukan apakah sebuah objek physics overlapping atau menabrak (colliding) dengan object physics lainnya, hasil dari collision detection adalah status apakah 2 buah objek menabrak (collide) dan apabila hal tersebut positif maka collision detection akan memberikan contact point yaitu titik dimana kedua objek tersebut bersentuhan bersama dengan parameter lainnya, seperti penetration depth, impact force, impact velocity dan lain-lain untuk digunakan pada proses perhitungan pergerakan objek physics selanjutnya.

3.3.3 Graphics Engine

Illustration 22: Collision Contact Point

Graphics engine berfungsi untuk mengolah seluruh data dan menampilkan data ini secara visual, proses ini dinamakan proses rendering, proses rendering minimal dilakukan sebanyak 30 kali dalam satu detik, setiap proses rendering dilakukan proses transformasi objek, texture mapping, pencahayaan, projection dan postProcessing. Pada proses transformasi dilakukan proses perubahaan koordinat objek berdasarkan ruang (space) tertentu sampai pada screen space yaitu ruang dua dimensi yang merupakan hasil akhir dari proses transformasi yang berupa kumpulan pixel pada layar yang dilihat oleh user. Proses transformasi ini dibutuhkan karena data visual umumnya berada pada ruang yang berbeda seperti posisi vertex dari mesh berada pada “object space” yaitu koordinate (0,0,0) berada pada pusat objek, kemudian setiap objek akan transformasikan pada “world space” dimana setiap objek memiliki data posisi dalam dunia game pada saat proses rendering akan dimulai, seluruh objek harus ditransformasikan pada “view space” yaitu posisi setiap elemen terhadap posisi view (eye/camera position), setelah proses rendering selesai, hasilnya berupa pixel yang harus ditransformasikan pada screen space atau yang dikenal dengan screen projection dan oleh operating system akan ditransformasikan lebih lanjut pada “window space”.


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 31 / 37

Illustration 23: Object Transformation

Selain pengaturan “space” dan transformasinya, dibutuhkan pula pengaturan berdasarkan hierarki dari sekumpulan objek yang akan dijelaskan lebih detail pada bagian 3.1.2.4. Texture mapping dilakukan untuk memberikan detail pada setiap objek yang berupa warna atau elemen visual lainnya sehingga hasil rendering dapat terlihat lebih realistik, proses texture mapping dilakukan dengan cara memetakan sebuah image (citra) pada setiap face (muka) dari mesh dengan menggunakan texture coordinate.

Illustration 24: Texture Mapping

Pencayahaan dilakukan untuk menambah realisme dengan memasukkan faktor dinamika cahaya yang diterima dari setiap objek, dengan adanya proses pencayahaan maka dapat diberikan efek material yang berbeda dari setiap objek, setiap objek dalam dunia visual diberikan efek material dengan cara menentukan beberapa variable yang menentukan bagaimana setiap permukaan objek bereaksi terhadap cahaya yang diberikan, beberapa variable umum yang digunakan diantaranya nilai diffuse, ambient, specular, reflectance, shininess, dan emissive dari setiap fragment pada setiap permukaan objek.


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 32 / 37

PostProcessing dilakukan pada setiap tahap akhir dari proses rendering dimana akan dilakukan proses terhadap setiap pixel yang akan ditampilkan pada layar, seperti pemberian “overlay” yang dapat berupa GUI dari game atau postProcessing untuk menambahkan efek-efek tertentu seperti motion blur, light bloom dan lain-lain Berikut adalah tahap-tahap yang dilakukan dalam setiap proses rendering secara lebih detail :

Illustration 25: Programmable Rendering Pipeline

3.3.4 Audio Engine Audio engine berfungsi untuk mengolah data dan event suara yang akan dikeluarkan oleh sound system PC, pemrosesan umumnya dilakukan pada DSP (SoundCard) ataupun CPU, beberapa proses yang dilakukan pada audio engine diantaranya pengolahan efek suara secara realtime, mixing, pengolahan environmental effect serta spatial dan temporal efect dari suara. Beberapa efek suara yang dilakukan pada sample suara untuk keperluan game diantaranya pitch shifting, echo, chorus, flanger, distortion, compressor, equalizer. Efek-efek ini umumnya digunakan untuk merubah sifat suara secara realtime berdasarkan variable tertentu, seperti sampel suara mesin dari mobil direkam


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 33 / 37

hanya pada RPM tertentu sedangkan dalam game dibutuhkan berubahan suara mesin berdasarkan nilai RPM dari mesin mobil dalam game, untuk itu diperlukan pemberian efek pitch shifting pada suara mesin sehingga semakin tinggi RPM maka semakin tinggi frekuensi sample suara yang akan dikeluarkan. Environmental efek digunakan untuk mensimulasikan dinamika suara secara realistis pada suatu lingkungan tertentu, dimana pada keadaan nyata suatu suara dan dipantulkan (reflected), diserap (absorbed) ataupun dihilangkan (occluded) apabila terinterferensi dengan suara lain. Pada game hal ini dilakukan dengan pemberian variabel tertentu pada setiap sumber suara kemudian dilakukan prosesing yang dikenal dengan environmental reverberation, beberapa variable yang digunakan untuk proses ini adalah densitas udara, faktor difusi udara, high frequancy air absorption factor, reverberation gain, decay time, faktor room rolloff dan decay ratio. Proses mixing dilakukan untuk menggambungkan beberapa sumber suara setelah dilakukan proses efek dan environmental, pada game umumnya terdapat lebih dari satu sumber suara, karena channel audio pada sound system PC terbatas (umumnya 2 channel untuk stereo hingga system 7.1 yang terdapat 8 speaker) maka diperlukan proses mixing berdasarkan jumlah channel suara dari PC, proses mixing ini akan mengakomodasi posisi dan orientasi dari sumber suara untuk dipetakan pada frekuensi dan channel tertentu sehingga akan memberikan efek positioning dari suara atau yang dikenal dengan proses HRTF (Head Related Transfer Function)

Illustration 26: HRTF based SOund

Pengolahan data spatial umumnya melakukan perhitungan kekuatan suara berdasarkan faktor attenuation Nomor Dokumen : DSG01

Nomor Revisi : 01

Tanggal 05/05/08

Halaman 34 / 37

dari sumber suara, dimana setiap sumber suara dalam game memiliki posisi tertentu terhadap posisi pendengar (listener) sehingga semakin jauh sumber suara dari pendengar maka kekuatan suara akan menurun (attenuated), begitu pula dengan faktor orientasi dari sumber suara. Pengolahan data temporal umumnya untuk mengakomodasi pergerakan sumber suara, dalam game sumber suara dapat dikeluarkan oleh sebuah entiti game yang bergerak dengan kecepatan tertentu, faktor kecepatan sumber suara memiliki faktor pada sifat akhir dari suara yang dikeluarkan ini, seperti faktor doppler.

3.3.5 Game Logics Game logics adalah modul yang sifatnya spesifik pada game tertentu, modul ini bersifat tidak portable seperti engine-engine diatas, dalam modul ini terdapat pengolahan event-event dari game, state dari game serta pemrosesan artificial intelligence.

3.3.6 Network Engine Network engine berguna untuk melakukan penerimaan dan pengiriman data pergerakan dan event dari seluruh entity game untuk keperluan multiplayer game mode, kecepatan pengiriman dari data ini akan terbatas oleh latency dari network dan besar data yang bisa dikirimkan akan dibatasi oleh bandwidth dari network, untuk itu setiap data yang akan disalurkan pada jaringan harus dilakukan prosessing lebih lanjut. Proses dalam network engine melibatkan proses dekompresi dan kompresi data, serta interpolasi dan extrapolasi dari data. Proses dekompresi dan kompresi berfungsi untuk meningkatkan efisiensi network dengan pemampatan ukuran data, sedangkan proses interpolasi dan extrapolasi digunakan untuk memprediksi event atau pergerakan entiti game. Proses extrapolasi digunakan untuk memprediksi pergerakan entity berdasarkan data yang dimiliki seperti vektor kecepatan, akselerasi dan force (gaya) yang dikirimkan untuk setiap entiti game, sehingga efek keterlambatan (delay) data yang diterima tidak terlalu signifikan terlihat pada layar game. Proses extrapolasi ini menggunakan algoritma yang dikenal dengan “Dead-Reckoning”, pada algoritma ini digunakan suatu nilai threshold tertentu yang disepakati oleh pengirim dan penerima sehingga data untuk meng-update hanya dikirim apabila parameter dari suatu entity diluar threshold, selain dari itu digunakan juga metode “time wrapping” untuk benda yang bergerak cepat dengan cara memundurkan waktu dan menghitung event yang terjadi sebelum data diterima.


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 35 / 37

Proses interpolasi digunakan sebagai fasilitas untuk smoothing pergerakan dari hasil update yang diterima, karena besar kemungkinan hasil extrapolasi dan data update yang diterima kemudian akan terdapat perbedaan, interpolasi digunakan untuk merubah parameter hasil extrapolasi menuju data update yang benar.

Illustration 27: Dead-Reckoning


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 36 / 37

4.Lampiran


Nomor Revisi : 01

Tanggal 05/05/08

Halaman 37 / 37

Dokumen Pengembangan Produk

Recommend Documents