Tips Dalam Mengomentari Source Code Anda

Beberapa minggu terakhir ini saya mengerjakan game dalam tim yang terdiri dari dua programmer, dan beberapa hari yang lalu saya diminta untuk menggantikan tugas seorang programmer di tim yang lebih besar lagi. Hal pertama yang terpikir oleh saya jika membicarakan tim dengan banyak programmer adalah ‘kodenya harus rapi dan well commented‘. Selain agar mudah dibaca jika sewaktu-waktu programmer lain dalam tim butuh untuk menambahkan kode di bagian saya, game yang besar berpeluang untuk berjalan dalam waktu yang cukup lama, sehingga pasti akan banyak penambahan fitur atau setidaknya maintenance.

Hal pertama yang saya lakukan adalah memanfaatkan fitur yang ada pada IDE yang saya gunakaan saat itu (FlashDevelop), yaitu fitur code snippetnya. Komentar saya dibuat sedemikian rupa sehingga tidak memakan banyak baris, namun tetap muncul di pop-up pada IDE (misalnya pada penjelasan fungsi atau parameternya). Sempat juga mencoba documentation generator seperti Ortelius, yang bisa terintegrasi dengan FlashDevelop untuk membuat dokumentasi, namun dibatalkan karena ada ketidakcocokan dengan format komentar yang saya gunakan.

Ada beberapa tips dalam membuat komentar pada source code, yang saya rangkum sebagai berikut:

1. Tulis komentar dengan rapi dan konsisten. Gunakan indentasi yang benar dan seragam, beri komentar untuk setiap properti dan fungsi yang dibuat.
2. Tulis komentar dengan jelas dan mudah dimengerti. Namun jangan menggangap remeh calon pembaca komentar Anda dengan menjelaskan “if(a==5)” dengan “//jika a sama dengan 5″. Asumsikan calon pembaca adalah sesama programmer atau diri Anda sendiri di masa depan.
3. Gunakan tag khusus jika perlu. Tag yang umum digunakan misalnya “//TODO:” atau “//FIXME:”
4. Tulis komentar selagi Anda membuat kode atau mengupdate kode. Karena percayalah, membuat komentar untuk kode yang sudah selesai sama merepotkannya dengan menulis ulang kode-kode itu.
5. Tambahan dari saya, “Tell what do you do, not how do you do“. Artinya beritahu apa pekerjaan Anda, bukan kabar Anda tulis tujuan dari sebuah bagian kode, bukan bagaimana kode tersebut bekerja. Misalnya “hitung c yang merupakan selisih b dan a”, tapi lebih baik “c adalah vektor AB”.

Sekian beberapa tips yang saya tahu, semoga bisa berguna untuk yang membutuhkan.

Cheers… :D

Game developer, Indie vs pro

Dari sini…

^Kantor Blizzard

Ada beberapa perbedaan mencolok antara developer independen dan pro (bekerja di perusahaan game dev besar), yang umumnya baru diketahui setelah bekerja cukup lama.
1. Tidak bisa menghentikan proyek begitu saja. Saat masih bekerja sendiri atau bersama grup gamedev kecil, tidak ada resiko yang perlu ditanggung jika proyek dihentikan, mungkin karena sibuk sekolah atau kuliah, mentok di programming, art asset yang belum selesai terlalu banyak,  atau karena tiba-tiba muncul ide brilian lain yang dijamin keren. Kita tidak akan bisa menghentikan proyek walau tim sudah tidak semangat, ide game ternyata tidak sesuai dengan selera kita, atau karena berbagai kendala teknis,, the game must go on.
2. Semua orang sama (atau lebih) berbakat dengan kita. Jika saat bekerja kita adalah programmer paling jago, desainer paling hebat, atau artist paling keren,, maka di perusahaan game bersiap-siaplah menjadi orang biasa. Kita paling pintar di sekolah? Kemungkinan besar mereka juga. Kita berpengalaman membuat dua puluh game sebelum lulus? Kemungkinan besar mereka juga. Satu-satunya cara menghadapi kondisi ini adalah dengan selalu siap belajar dan belajar lebih banyak lagi.
3. Game development adalah kegiatan utama kita. Cukup obvious tapi kadang orang underestimate pekerjaan pro. Jika berawal dari hobi dan biasanya bisa fokus dua jam tiap hari, sekarang harus bisa fokus minimal delapan jam. Untuk orang yang kurang siap maka ini bisa menjadi tantangan tersendiri,, namun jika ini memang hal yang kita inginkan maka justru ini adalah hal yang bagus. :D
4. Kita membuat game untuk mendapatkan uang. Jika diawali dengan motivasi membuat game untuk menyalurkan kreatifitas kita, atau semata impian sejak kecil, kita harus bersiap-siap, karena motivasi utama di dunia kerja adalah mencari uang. Jika kita membuat game yang memenangkan semua award yang ada, namun penjualan hanya dua puluh ribu koi dari target lime juta kita tetap gagal. Bahkan hal tersebut bisa membuat perusahaan kita bangkrut. Tapi perlu diingat, membuat game untuk mencari uang tidak berarti kita akan kehilangan soul game developer, hanya saja kita memiliki tanggung jawab lebih besar.

Dari saya pribadi, perbedaan yang saya rasakan adalah masalah tanggung jawab… ._. Demi teman-teman sejawat yang sama-sama membangun Agate…

Flash on iPhone, berita baik atau buruk?

Terkait post saya beberapa hari yang lalu tentang flash untuk iphone, ada beberapa pendapat terkait hal tersebut…

Jumlah game di itunes app store katanya mencapai 17000,, walau masih kalah dengan flash game yang menurut saya angkanya pasti jauh lebih banyak lagi. Lalu apa masalahnya? Dengan jumlah yang sebanyak itu, akan banyak game dengan kualitas biasa saja di pasaran, otomatis akan membingungkan pengguna dalam memilih atau membeli game.

Secara teknis,, aplikasi bisa berjalan lebih lambat karena keterbatasan kemampuan hardware. Lalu ada yang berpendapat tidak semua jenis game bisa di-port ke iphone terkait dengan controllernya. iphone walau memiliki layar sentuh tidak memiliki tombol-tombol fisik seperti keyboard.

Kalau menurut saya sendiri,, bisnis game flash dan game iphone cukup jauh berbeda. Yang satu umumnya berbasis sponsorship, ads, dan hit, sedangkan yang satunya berbasis online store, baik trial atau full version. Jadi untuk masuk ke pasar iphone tidak cukup hanya bermodal  game flash yang bagus lalu di port begitu saja, tapi harus mempertimbangkan aspek bisnisnya.

Kesimpulan akhir dari saya: flash untuk iphone secara teknologi itu bagus,, tapi untuk bisnis perlu dipikirkan lebih lanjut :D

Bagaimana menurut kalian? Tertarik menggunakan flash untuk develop ke iphone?

Ebook ShaderX gratis

Saya lupa udah pernah ngasih link ini ato belum…
isinya ada dua buku pertama seri ShaderX dalam bentuk pdf, dan gratis! :D

Trus ada satu lagi, D3DBook, buku online gratis tentang vertex, geometry, dan pixel shader.

Lumayan buat yang mau belajar shader, mengurangi ketinggalan dari orang luar :p

Cheers :D

Game XBLA sekarang boleh mencapai 2GB

Dari sini…

Berita baik untuk developer game untuk XBLA, karena sebelumnya game XBLA dibatasi ukurannya sebesar sekecil 150MB, sekarang game XBLA bisa sampai 2GB.

Dan sekedar informasi, 2GB itu juga bukan batasan, tapi lebih berupa keterbatasan teknologi.

Anyway, ini mungkin salah satu alasan kenapa batasan 150MB dihilangkan:

E3 2009 Shadow Complex Trailer HD

Yup, it’s on the freakin XBLA… -o-

Gamedev Video :Game Design – Raising the Bar

Dari sini.

“Will Wright, Sid Meier, Shigeru Miyamoto… we all know the names. But how do today’s top designers always stay ahead of the game? Season 2 continues as we take a closer look at the qualities that define today’s most celebrated talents, and what it takes to make a hit in 2009. Join us as we discover how even living legends have had to adapt to keep pace with the constantly evolving game industry – and what changes these radical shifts herald for the entire field. Plus, how to score a job in game design, and whether or not pros still have a place in the age of user-generated content.”

Di video itu dibahas berbagai hal mengenai game designer saat ini. Ada beberapa poin menarik yang saya ambil dari video tersebut :

• Untuk seorang game designer : creativity is number one
• Ada dua sifat yang dimiliki game designer hebat :
  1. Maturity : seorang game designer harus bisa bersikap dewasa,, jika ada sesuatu yang harus dibuang demi penyelesaian game maka dia harus bisa berbesar hati
  2. Humble : seorang game designer yang baik harus bisa menerima kritik dan orang-orang yang memainkan gamenya, demi membuat game design yang lebih baik lagi
• Polishing game tidak hanya dilakukan di akhir pengerjaan game, tapi sebaiknya dilakukan sejak awal game dibuat
• Game designer yang baik harus bisa membuat proses game development dalam iterasi. Jadi dia bisa berkata pada tim “jangan menghabiskan waktu untuk bagian ini agar dapat kita ubah atau sesuaikan dengan mudah”

Develop Magazine July 2009 is out

Dari sini.

Majalah bulanan Develop Magazine sudah terbit edisi 96, Juli 2009. Bisa didownload dalam bentuk PDF, atau baca langsung di browser.

Isinya berita tentang dunia game development. Padat, berbobot, dan GRATIS :D

Cheers… :D

FPS tidak relevan terhadap performance

Dari sini.

Cara untuk mengetahui performa adalah dengan mengukurnya, tapi sayang banyak paper yang mengukur dengan buruk. Contoh paling umum adalah mengukur dengan satuan FPS / Frame Per Second seperti pada paper ini.

FPS is useless.
Gamer mungkin senang dengan FPS, dan benchmark komputer umumnya menampilkan FPS, tapi game developer berbicara dalam milisecond. Kenapa? Karena secara definisi, frame per second itu mencakup semua hal yang terjadi dalam frame, bahkan hal-hal yang bukan bagian utama dari teknik rendering.
Pada contoh paper diatas, SSDO adalah teknik post processing, dan setiap GPU butuh buffer clear dan main scene rendering adalah tidak relevan. Dan karena terjadi pada satu frame yang sama, sehingga tidak bisa diketahui berapa FPS biaya proses-proses tersebut.
Contohnya mereka bilang bahwa ada overhead 2,4% pada SSDO vs SSAO, padahal SSDO bisa saja dua kali lebih lambat dari SSAO, tapi proses lain menutupi fakta tersebut.
Misalnya main scene rendering perlu 12ms, SSAO 0,5ms, sehingga total 12,5ms dengan FPS 80. Jika SSDO ternyata 1ms, total jadi 13ms, 77 FPS. Penurunan  framerate hanya 4% walau sebenarnya cost SSDO dua kali lipat SSAO.

FPS tidak bisa menunjukkan apa yang mahal dan tidak.
Jika kita menjalankan game dengan 20 FPS dan menambah proses 1ms, framerate menjadi 19,4 FPS, penurunan yang terlihat tidak signifikan. Namun jika kita menjalankan game 100 FPS dan menambahkan tepat 1ms yang sama, framerate turun menjadi 90,9 FPS, sebuah penurunan yang lebih besar baik dari angka FPS atau dengan persentase.

FPS tidak valid untuk dirata-ratakan.
Jika kita merender tiga frame dalam 4ms, 4ms, dan 100ms, kita dapat rata-rata FPS :
(1000/4 + 1000/4 + 1000 / 100) / 3 = 170 FPS.
Sedangkan jika merender dalam 10ms, 10ms, dan 10ms kita akan mendapat rata-rata FPS :
(1000/10 + 1000/10 + 1000/10) / 3 = 100 FPS.
Proses render kedua, selain selesai dalam 30ms (dibanding 108ms), namun juga lebih stabil, namun mendapat rata-rata FPS jauh lebih rendah.

Verdict : STOP USING FPS as performance measurement. Use miliseconds instead. D:

*SSDO = Screen Space Directional Occlusion
*SSAO = Screen Space Ambient Occlusion