Pages

Minggu, 22 April 2012

Arsitektur Mesin Game

Mau bikin apa - apa harus direncanakan seperti lagunya Dik Doank "Plan plan planning", tapi di lagu itu isinya tentang arsitektur buat bikin anak. yang mau dibahas sekarang soal "Arsitektur Game". Isinya kira - kira seperti dibawah ini.


1. Sistem Inti (dasar) di dalam game

Di bagian ini biasanya terdiri dari Struktur basis data, File handling, alokasi memori dan semuanya yang berhuibungan dengan konseptual. Termasuk juga logika matematika (hall ini bisa terjadi di dalam game yang membutuhkan Lifetime) limit kehidupan untuk suatu karakter. seperti misalnya yang terdapat didalam game - game FPS dan RPG, contoh lainnya masih banyak, pokoknya berhubungan sama kematian suatu karakter, yang paling populer adalah sistem darah di dalam DOTA, game paling populer sejagad. Di dalam perhitungan logika matematika sangat terlihat, di dalam DOTA sendiri terdapat equip defense yang berupa armor dan epuip attack berupa senjata yang memberikan nilai tambah serangannya. Apabila senjata yang dipakai memiliki +4 dan armor yang diserang memiliki armor +3 maka hasil yang masuk hanyak damage asli +1. ibaratnya begitu, namun di game tentunya lebih kompleks, rumit dan saya tidak berharap melihat kodingnya dalam bentuk bahasa pemrograman apapun. Itu contoh logika begonya aja.

Masalah konsep, mainkan saja setiap game yang anda suka, pasti semuanya terstruktur namun pemakai tentunya banyak yang mengabaikan hal tersebut, mereka hanya membutuhkan kepuasan setelah bermain, tergantung juga tujuannya bermain game itu apa.

File handling, berisi tentang gimana ya jelasinnya. Contohnya seperti menyimpan suatu game di dalam keadaan tertentu. Jikalau anda pernah memainkan game Pro Evolution Soccer "Become a Legend" atau "Master League" atau game apapun yang ada save-loadnya, setelah anda bermain tentunya di save dan data tersebut terbuat secara otomatis, ga otomatis juga sih, progammer yang membuat file tersebut tercipta pas pemain memutuskan game tersebut untuk di save. Jadi data yang tersimpan ya keadaan terakhir waktu di save. Namun apabila di tengah permainan, listrik dirumah anda padam atau karena gejala non teknis lainnya, secara otomatis data yang tadi akan tersimpan "di keadaan kalah, karena permainan belum berakhir" Logika yang ditangkap adalah para pemainnya rame - rame bersama manager dan jajarannya kabur dari medan laga. Hal ini berarti di dalam setiap keadaan apapun termasuk ketika program dijalankan, suatu file terbentuk dan menyimpan kode - kode (yang bikin mumet) secara Real TIme dan dalam keadaan terakhir.
Mungkin logika programnya seperti ini kali ya :

class System

{

public:
static boolean Load (const char* NamaFile, char*& racBuffer,
int& riSize);
static boolean Save (const char* NamaFile,
const char* acBuffer, int iSize);
static boolean Append (const char* NamaFile, char* acBuffer,
int iSize);
};


2. Grafik dan Rendering

Grafik ya, hubungannya sama bagus - bagusan warna dan dimensi. Untuk grafik 2 dimensi biasanya ga perlu hardware yang wahhh, tapi kalo untuk grafik berbasis 3D baru beli PC impian, secara game udah berkembang pesat seiring dengan kemajuan teknologi. Yang biasanya pembuat game pakai untuk 3D itu Open GL dan Direct 3D. Masalah perbedaanya Googling aja.

Yang perlu diperhatikan apabila ingin membuat game berbasis 3D :
  • Berapa banyak data yang perlu di render pada saat itu juga, saat game dimainkan (Real Time) 
  • Bagaimana Interface yang terpampang ketika di render
  • Seberapa gampang software untuk dipakai programmer, kalo susah tinggalkan saja, ganti jadi penikmat aja kalo niat lanjutkan usahamu.
  • Support dari kreasi yang sebelumnya, maksudnya kalo mau nambah kreasi baru hasilnya mumpuni ga sama hasil yang udah dibuat sebelumnya.

Geometri

Umumnya dialokasiin pake array tapi ya tergantung masing - masing. misalnya array V[i] for 0 ≤ i < n. dan nantinya akan digunakan untuk tanda, dalam contoh yang dipakai adalah segitiga. Jadi misalnya titik - titik segitiga dijadiin (i0,i1,i2) dan dihubungkan di verteks array (V[i0],V[i1],V[i2]). Di dalam 3D bisa dirubah seperti diperbesar, diperkecil ,di plengosin ke dalam dan keluar, Trigger yang dipakai yaitu verteks array tadi yang nantinya posisi nya tersimpan i variabel (i0,i1,i2). kira - kira seperti itulah.

 

Spatial (Tata Ruang)

Dimari yang dibahas soal penempatan suatu objek di dalam game. Ga mungkin kan  orang bisa lebih gede dari rumah, atau senjata yang dibawa lebih besar dari pegangan tangan terus dibawa lari kemana - mana. Makanya Geometri mempunyai pengaruh besar disini.

Node (Simpul)

Sebenarnya ga cocok juga dibilang simpul. soalnya bentuknya begini.
jadi didalam rumah itu ada 2 ruangan, sisanya liat gambar aja. Intinya cuma buat ngejelasin di dalam suatu objek masih memungkinkan ada objek apa lagi yang membuat suatu terlihat menarik.Untuk lebih lanjutnya bisa dilihat ilustrasi berikut ini
Jadi maksudnya semuanya terintegrasi masing - masing. Untuk mengubah suatu ruangan ga perlu lagi untuk mengubah meja, pisau atau objek yang ada didalamnya. Pemicunya ada di Ruangan yang menjadi Parent dari objek tersebut, bakalan lebih ribet kalo ngatur satu - satu. Hal ini mengefisienkan transformasi apabila ingin semuanya terlihat realistis.

kira - kira seperti ini kalo di program :


class Node : public Spatial

{
public:
Node (int iQuantity = 1, int iGrowBy = 1);
virtual ~Node ();
int GetQuantity () const;
int GetUsed () const;
int AttachChild (Spatial* pkChild);
int DetachChild (Spatial* pkChild);
SpatialPtr DetachChildAt (int i);
SpatialPtr SetChild (int i, Spatial* pkChild);
SpatialPtr GetChild (int i);
protected:
TArray m_kChild;
int m_iUsed;
};

Render

Secara ga langsung ini dia proses akhir untuk pembuatan dunia didalam game. Jadi setelah proses Node klop. Dunianya tertata, skala antar objek udah OK, Yakin 100% udah siap di render. maka renderlah.Rendering juga harus memperhatikan atribut verteks, shading , texture map atau apa saja yang dibutuhkan untuk menggambar suatu objek.


Controller & Modifier

Setelah semua siap, dunia didalam game maksudnya. Pemrogram harus memberikan konteks untuk pemain bagaimana menggerakkan suatu objek ataupun karakter pada saat bermain. waduh ini rada ribet juga ni, rada panjang soalnya. Misalnya nih, contoller itu harus pas ketika digerakkan jalan - jalan atau melakukan gerakan apapun dengan arah sinar yang datang, kalo di kehidupan nyata mirip sama orang lagi jalan dibawah terik matahari dan badan yang kena sinar datang menjadi lebih terang daripada yang tidak terkena sinar. Karena setiap keadaan di dalam game itu ada koordinatnya maka harus pas juga teksurnya.

Solusi dari Controller dan Modifier adalah dengan membuat daftar controller yang berhubungan dengan setiap anggota dari suatu objek. Jadinya setiap controller menangani objek yang dibawa setiap class di dalam program. Konsep seperti ini bagus karena tidak perlu untuk merancang ulang program. Setelah membuat sistem yang seperti itu, jalannya sebuah program menjadi kuat karena sesuai dengan Object Oriented Programming.

Tidak ada komentar: