Setelah beberapa tahun, social games tetap menjadi komoditas potensial yang cukup menarik bukan hanya bagi game company tetapi juga perusahaan yang ga bergerak dalam bidang game.
Walaupun sedikit terlambat, beberapa tahun terakhir mulai banyak perusahaan lokal yang tertarik untuk membuat aplikasi atau game, baik untuk menghasilkan income ataupun untuk membantu pemasaran produk/brand (adver-games). Sayangnya karena ketidakpahaman atau keterbatasan informasi mengenai proses pembuatan social game, banyak orang yang mengira bahwa proses pembuatan social game sama dengan pembuatan mini games. Keterbatasan informasi ini bisa dimaklumi karena setahu saya ga banyak developer yang mempublikasikan proses yang mereka jalani dalam membuat social game.
Dalam artikel ini, saya akan sedikit menjelaskan proses pembuatan social game (facebook) berdasarkan pengalaman saya di Playdom dan Hands On Entertainment. Selain untuk Anda yang ingin tahu proses pembuatan social/online game, artikel ini juga saya tujukan untuk membantu developer yang ingin melakukan pitching atau mengedukasi calon klien supaya ga ada yang bilang,
Buat game yang sederhana aja, seperti Farm Ville gitu.
Sebagai catatan, artikel ini mengacu pada pembuatan game yang dimaksudkan untuk bertahan dalam jangka panjang, bukan game sesaat yang sekedar nongol terus dibiarin mati dan saya ga membahas proses perancangan sebuah game karena proses ini terlalu spesifik.
Perencanaan
Tahap pertama dari setiap proyek, game atau bukan adalah perencanaan. Perencanaan yang baik akan mempermudah kita memperoleh hasil akhir yang baik. Sebaliknya, perencanaan yang asal-asalan akan memberi kita hasil yang juga asal-asalan.
Fail to plan, plan to fail
Ungkapan di atas adalah ungkapan populer dalam dunia pemrograman yang artinya “gagal berencana sama dengan berencana untuk gagal”. Ini untuk memperingatkan programer pemula yang seringkali terburu-buru menulis kode tanpa perencanaan. Ungkapan ini berlaku dalam semua jenis proyek, apapun bidangnya, IT maupun non-IT.
Perencanaan yang saya maksud di sini bukan hanya perencanaan (desain) game, tetapi juga perencanaan eksekusi proyek. Saya sering bertemu klien atau calon klien yang dalam perencanaannya hanya fokus pada produk akhir dan ga memperhitungkan faktor-faktor pendukung lainnya seperti infrastruktur, komunikasi, manajemen proyek, dan lain-lain. Parahnya lagi, sebagian dari mereka ternyata ga begitu peduli dengan faktor-faktor tersebut, khususnya masalah komunikasi dan manajemen proyek, yang penting mereka sediain duit & maunya tau beres. Menghadapi klien seperti ini, saya selalu menegaskan bahwa semua orang yang terlibat bertanggungjawab atas keberhasilan dan kegagalan proyek, termasuk mereka juga.
Apa saja yang perlu kita rencanakan sebelum memulai proyek?
Adalah kesalahan fatal kalo kita menggunakan server minimalis kecuali untuk keperluan development dan testing. Memang infrastruktur adalah komponen biaya yang ga kecil, tapi kalo kita memang serius dan ingin game buatan kita dimainkan banyak orang, kita harus menyiapkan infrastruktur yang solid. Sebagai contoh, untuk game yang dimainkan oleh puluhan bahkan mungkin ratusan juta orang termasuk saya dan Anda juga, Zynga menyiapkan data-center yang berisi lebih dari 1000 (seribu) server yang terbagi dalam beberapa kelompok : application server, game server, database server, content-delivery dan lain-lain.
Bukan berarti kita wajib memiliki data-center seperti Zynga, tapi maksud saya adalah, kita perlu menyediakan infrastruktur terutama server sesuai dengan target DAU (daily active users) atau CCU (concurrently connected users) jika kita akan membuat game realtime multi-player.
Kita perlu menyiapkan minimal 3 server yaitu:
Server
Development Server kita gunakan selama proses development. Server ini boleh (dan harus) diutak-atik programer setiap hari. Server ini berfungsi sebagai sandbox di mana programer melakukan testing dan deployment setiap saat.
Staging Server kita gunakan untuk keperluan testing/quality control sebelum kita melakukan release ke live server.
Production/Live Server adalah server yang diakses oleh publik/user.
Semua server bisa terpisah secara fisik (dedicated) atau virtual. Paling baik, untuk live server kita sewa dedicated server tapi untuk menghemat biaya, dalam banyak kasus di mana DAU ga terlalu besar, VPS (virtual private server) di mana kita berbagi pakai sebuah unit komputer server dengan orang lain sudah cukup baik. Shared-hosting dengan biaya murah sebaiknya dihindari karena banyak provider yang menjejalkan terlalu banyak user dalam satu unit komputer (oversell) sehingga akan mempengaruhi performance game kita. Untuk keperluan development dan testing, kita ga perlu dedicated server karena VPS sudah lebih dari cukup.
Kita bisa mulai proyek dengan satu VPS yang kita gunakan untuk keperluan development dan testing. Namun sebaiknya kita punya minimal dua VPS, satu untuk development, satu untuk staging (testing). Kenapa server development dan staging perlu terpisah? Tujuannya adalah agar kita bisa melakukan testing dalam kondisi terisolasi dan ga terpengaruh faktor lain. Development server adalah server yang setiap hari diutak-atik oleh programer dan ada kemungkinan mereka menyebabkan server crash, memory leak, dan lain-lain yang akhirnya mempengaruhi proses staging jika kedua server ga terisolasi.
Faktor berikutnya adalah lokasi server. Kita perlu memilih lokasi server yang terdekat dengan target pasar/konsumen. Untuk konsumen lokal, kita bisa menggunakan server yang ada di Jakarta atau Singapura.
Berikut ini beberapa provider yang bisa saya rekomendasikan:
Linode . VPS dengan salah satu data-center di Singapura.
Webfaction. Shared-hosting dengan performance dan fitur setara VPS. Salah satu data center ada di Singapura.
Futurehosting. VPS atau dedicated server. Data center di Amerika.
WiredTree. VPS atau dedicated server. Data center di Amerika.
Saya ga merekomendasikan produk Amazon selain Amazon S3 (content-delivery) karena struktur harganya yang membingungkan dan pada akhirnya biaya yang kita keluarkan juga lebih tinggi daripada kalo kita menggunakan jasa hosting yang lain.
Anda juga bisa window-shopping di forum Webhostingtalk untuk melihat tawaran-tawaran hosting dari berbagai provider di seluruh dunia.
Version Control & Code repository
Selain server untuk game dan aplikasi pendukungnya, kita perlu menyiapkan apa yang disebut version control yang digunakan oleh programer untuk berkolaborasi dan menyimpan source code. Dengan menggunakan repositori, programer ga perlu melakukan upload secara manual ke development, staging, ataupun live server sehingga akan menghemat waktu dan juga meminimalkan konflik.
Kalo Anda ga pernah dengar istilah version control, silakan baca ebook yang saya tulis berjudul Mengenal Git.
Kalo Anda mau, Anda bisa membuat repositori di server Anda sendiri. Tapi menurut saya lebih enak kalo kita menggunakan jasa repository hosting seperti Beanstalk, Github, atau Bitbucket. Ga perlu repot instal dan maintenance. Plus mereka menyediakan banyak fitur yang semakin mempermudah pekerjaan kita seperti automated-deployment, commit hooks, dan lain-lain.
Komunikasi & Project Management
Salah satu hal yang sering dilupakan adalah bagaimana cara kita berkomunikasi. Dari pengalaman, saya bisa pastikan email saja ga cukup untuk berkomunikasi, terutama kalo banyak orang yang terlibat. Kita butuh sarana yang memungkinkan kita untuk :
Mengelompokkan diskusi berdasarkan topik atau bagian. Misalnya, diskusi tentang perencanaan kita kelompokkan dalam grup “Planning”, laporan bug kita kelompokkan dalam grup “Bug”, masalah server dalam grup “Server”, dan sebagainya.
Mengambil web link sebuah diskusi atau komentar untuk keperluan referensi. Misalnya, klien menulis komentar dalam thread diskusi B, kita bisa dengan mudah mem-bookmark komentar ini dan membagikannya.
Memastikan semua orang membaca sebuah diskusi minimal mendapat notifikasi. Berapa kali kita lupa cc saat menulis email?
Membaca thread yang panjang ga pake pusing dan sakit mata. Saya ga tahu bagaimana dengan Anda, tapi thread email yang panjang sering bikin saya pusing. Apalagi kalo posting-nya ga berurutan, bisa mual dan nggreges.
Banyak proyek yang gagal hanya karena masalah komunikasi. Jadi, kita ga boleh menganggap remeh masalah ini.
Untuk mempermudah komunikasi, kita bisa menggunakan project management software. Kita bisa pilih software online atau offline sesuai kebutuhan. Project Management Software menyediakan banyak fitur seperti forum diskusi, kumpulan catatan/referensi baik berupa teks atau file, berbagi pakai dokumen, penjadwalan, dan sebagainya. Bebeapa provider juga menyediakan version control dalam paket-paketnya. Berikut ini beberapa layanan online yang saya rekomendasikan:
Ada dua metodologi dalam pengembangan software yaitu:
Waterfall
Agile
Waterfall adalah metodologi klasik yang sudah bertahun-tahun diterapkan dalam industri software. Dalam metodologi ini, kita berusaha membuat rencana (spesifikasi) yang sesempurna mungkin sebelum proyek dijalankan. Karena dibuat di depan, rencana kita bersifat kaku dan hampir bisa dipastikan perubahan rencana di tengah jalan akan menyebabkan proyek mundur atau menyebabkan biaya (cost) tinggi. Namun begitu, metodologi ini masih tetap populer karena mudah dijalankan dan ga membutuhkan skill khusus.
Metode modern yang mulai populer pada awal tahun 2000-an disebut Agile Methodology. Metode ini terinspirasi dari industri otomotif di Jepang yang sangat efisien dan produktif jika dibandingkan dengan industri serupa di Eropa dan Amerika. Dalam metodologi ini, kita membuat perencanaan secukupnya sebelum proyek dimulai. Proyek dibagi dalam beberapa siklus singkat (2 – 4 minggu) yang disebut sprint di mana setiap sprint diawali dengan planning diakhiri dengan release.
Metode Agile terbukti sangat fleksibel dan memungkinkan kita mengubah spesifikasi di tengah jalan dengan biaya (cost) minimal. Agar dapat menjalankan metode ini, kita membutuhkan programer yang kompeten dan berpengalaman dalam membuat arsitektur yang fleksibel. Mencari programer seperti ini bukan perkara mudah. Banyak programer yang sudah berpengalaman tapi ga bisa membuat arsitektur yang fleksibel, kode yang mereka tulis ga fleksibel sehingga sulit untuk diubah di tengah jalan. Programer yang kita cari adalah programer yang ga hanya bisa menulis kode tetapi juga mengerti kelebihan dan kekurangan bahasa yang mereka gunakan serta, utamanya, mengerti apa yang disebut Design Patterns dan tahu cara membuat framework juga terbiasa mempraktekkan best-practices. Bukan berarti semua programer dalam tim kita harus sekaliber ini, minimal kita punya satu atau dua orang yang mumpuni dan bisa menjadi mentor programer lain yang skill-nya di bawah mereka.
Perbedaan lain yang cukup signifikan antara agile dan waterfall adalah release target. Dalam metodologi Agile, release dilakukan secara berkala dan dalam fase-fase awal, targetnya adalah minimum viable product yaitu produk dengan fitur minimal tetapi sudah bisa digunakan. Sementara dalam metodologi waterfall targetnya adalah complete product. Tim yang menggunakan metodologi agile bisa melakukan release lebih cepat dan lebih sering daripada tim yang menggunakan metodologi waterfall walaupun hasil akhirnya nanti juga sama.
Ada dua implementasi metodologi Agile yang banyak dipraktekkan dalam industri software yaitu:
Scrum
Kanban
Metode Agile ga mungkin dijelaskan dalam artikel ini tapi saya berencana menulis artikel khusus mengenai Scrum di lain waktu berdasarkan pengalaman saya bekerja di Hands On Entertainment. Untuk sementara, kalo Anda tertarik silakan tanya Oom Google.
Satu hal lagi, sebelum kita memulai proyek ada baiknya kita tulis dalam proposal metode apa yang akan kita pakai sehingga orang-orang yang terlibat bisa membayangkan seperti apa siklus proyek nantinya. Ga masalah metode mana yang kita pilih, asalkan kita siap dengan konsekuensinya dan bisa mengantisipasi perubahan-perubahan di tengah jalan.
Hal lain yang perlu dijelaskan di awal adalah:
Peran setiap orang. Siapa yang bertanggung jawab membuat framework, siapa yang menangani proses release, dan sebagainya. Satu peran bisa dijalankan oleh beberapa orang. Satu orang bisa menangani beberapa peran.
Quality control. Bagaimana menjamin kode yang ditulis satu orang ga menimbulkan konflik dengan kode yang ditulis orang lain? Apa kita akan mengadakan code review? Dan sebagainya.
Standar penulisan kode. Di sini kita menentukan format penulisan kode dengan tujuan agar kode yang ditulis oleh seseorang bisa dipahami dan dilanjutkan oleh orang lain.
Perencanaan
Kecuali kita menyewa paranormal seperti Ki Joko Bodo, ga mungkin kita membuat rencana yang benar-benar solid dan akurat. Dalam dunia pemrograman ada ungkapan berikut.
The only constant is change
Artinya, satu-satunya hal yang pasti dalam pembuatan software adalah perubahan. Maksudnya, ga peduli sebagus apa rencana yang kita buat, pasti di tengah jalan kita harus melakukan perubahan. Karena itu, proses perencanaan ga akan pernah berhenti. Perencanaan dan perubahan rencana harus didiskusikan dan didokumentasikan secara baik sehingga bisa dijadikan referensi.
Untuk proyek game, umumnya ada dua dokumen penting yang harus dibaca semua orang yaitu:
Game Design Document (GDD). Berisi rancangan game, target pasar, monetization, cara memainkannya, unsur-unsur challenge, rewards, grafis, animasi, dsb.
Technical Design Document (TDD). Berisi rancangan teknis antara lain berapa server yang digunakan & sistem operasinya, metode deployment, koneksi dengan version control system, format data, dsb.
Development
Proses development ga hanya menyangkut pemrograman tetapi juga pembuatan aset grafis, animasi, dan sebagainya. Termasuk dalam proses ini adalah internal testing yang dilakukan oleh tim programer. Selama proses ini sebaiknya para programer ga “diganggu” dengan permintaan yang bermacam-macam baik oleh project manager ataupun klien. Semua permintaan/rekues harus diberi bobot prioritas, yang ga berprioritas tinggi dan bisa ditunda sebaiknya ditunda sampai tim programer selesai mengerjakan task yang sedang mereka tangani.
Proses development pada dasarnya terbagi dalam dua macam yaitu feature addition dan bug fixing.
Feature Addition
Dalam proses ini, tim programer menambahkan fitur baru ke dalam game. Fitur-fitur yang akan ditambahkan perlu dikelompokkan berdasarkan:
Prioritas
Dependency (ketergantungan) karena mungkin saja sebuah fitur baru bisa ditambahkan kalo fitur lain sudah ada.
Tim programer dan project manager akan menyusun jadwal berdasarkan kedua faktor di atas.
Bug-fixing
Setiap bug yang dilaporkan akan ditangani tim programer berdasarkan prioritasnya. Setelah bug diperbaiki, tim programer bertanggungjawab untuk memberitahu pembuat bug report bahwa bug bisa diuji kembali pada fase staging berikutnya. Jadi, tim programer wajib menyediakan daftar bug yang udah dibenerin & siap dites lagi.
Bug-fixing harus lebih diutamakan daripada feature addition.
Staging (Testing/QC)
Ketika tim programer menyelesaikan sejumlah task dan game bisa diuji, mereka atau orang yang ditunjuk akan melakukan proses yang melakukan upload atau deployment kode dan segala aset pendukungnya ke staging server. Game selanjutnya diuji oleh tim penguji (tester). Proses ini ditujukan untuk quality control yaitu menguji produk sebelum dilepas ke publik (live server).
Pengujian sebaiknya dilakukan oleh orang-orang di luar tim programer karena beberapa alasan:
Orang di luar tim developer bisa menguji produk dengan lebih obyektif
Tim developer terbiasa menguji produk dengan cara dan urutan yang sama berulangkali. Orang lain menguji produk dengan urutan dan cara yang acak sehingga bisa menemukan bug yang mungkin terlewatkan oleh developer.
Orang di luar tim developer mungkin menggunakan Sistem Operasi dan browser yang berbeda-beda sehingga bisa menemukan isu atau masalah kompatibilitas.
Tim programer hampir pasti ga punya waktu untuk melakukan pengujian menyeluruh dan mengkover bermacam-macam skenario (OS, browser, urutan aksi).
Bug yang ditemukan selama pengujian harus didokumentasikan. Proses ini makan waktu juga.
Dokumentasi Bug
Sebelum melakukan testing, tim penguji perlu dibekali dengan pengetahuan tentang cara menguji dan mendokumentasikan bug. Beberapa aturan umum yang sering dipraktekkan :
Waktu melakukan pengujian, sistem/komputer si penguji harus bebas dari proses/program lain yang mungkin mempengaruhi pengujian. Misalnya:
background process bisa mempengaruhi performa game yang diuji jadi jangan menguji game sambil browsing atau nonton Youtube
browser plugin/extension yang ga perlu harus dinonaktifkan
Sebuah masalah baru bisa disebut bug kalo bisa direproduksi/diulangi oleh si penguji. Kalau si penguji ga bisa mengulangi bug, apalagi tim programer.
Tim penguji ga boleh melaporkan sebuah bug yang udah pernah dilaporkan tapi belum diperbaiki oleh tim programer supaya ga ada double-entry. Jadi sebelum membuat laporan, tim penguji harus mengecek daftar bug yang udah ada.
Dokumentasi bug yang baik berisi:
Tanggal dan waktu pengujian
Cara-cara untuk mereproduksi (mengulangi) bug tersebut
Screenshot yang memperlihatkan kondisi pada waktu bug terjadi (kalo bug bisa dilihat secara visual)
OS, Browser, dan versi plugin yang digunakan oleh penguji
Prioritas, sebagai acuan tim programer dalam melakukan scheduling
Semua bug yang didokumentasikan dikumpulkan di satu tempat dan dikelompokkan berdasarkan kategori misalnya kategori ui untuk bug yang berkaitan dengan user interface, kategori gameplay untuk bug yang berkaitan dengan game itu sendiri, dan sebagainya. Semua project management software mempermudah kita melakukan dokumentasi, pengumpulan, dan pengelompokkan bug reports bahkan memungkinkan kita mengkonversi bug report menjadi task.
Salah satu penyakit yang sering bikin jengkel adalah tim penguji yang berulangkali melaporkan bug yang sama padahal bug itu memang belum kita benerin atau mereka seenaknya memberi prioritas tinggi pada semua bug tidak peduli apa bug itu benar-benar krusial atau ga. Di sini peran project manager atau lead programmer sangat penting untuk memfilter laporan-laporan yang ga perlu.
Deployment/Release
Deployment
Setelah tim programer menyelesaikan beberapa task (tugas), mereka melakukan deployment ke staging server. Proses deployment ini juga harus dilengkapi dengan dokumentasi mengenai task mana saja yang sudah dikerjakan sehingga tim penguji bisa fokus pada task tersebut.
Kalo kita menggunakan version control, kita bisa memanfaatkan fitur tag untuk menandai commit atau update terakhir yang disertakan dalam staging. Contohnya, kita bisa memberi tag “staging 01 Januari 2013”, “staging 20 Januari 2013”, “release 10 Februari 2013”, dan sebagainya.
Kalo dalam proses staging tidak ditemukan bug yang fatal (menyebabkan error kelas berat, seperti crash, hang, dsb), berikutnya kita bisa melakukan release ke live server. Sama dengan proses staging, tim programer juga perlu menandai update terakhir yang disertakan dalam proses release. Kenapa? Supaya kalo terjadi apa-apa, ada error dsb, kita mudah melakukan rollback (kembali ke versi release sebelumnya).
Version control hosting biasanya menyediakan sarana untuk melakukan deployment melalui web interface dan deployment yang dilakukan otomatis dicatat oleh sistem sehingga kita mudah melakukan rollback.
Sebaiknya kita menginformasikan rencana deployment kepada user dan tim penguji. Lebih baik lagi kalo kita sementara menon-aktifkan game sampai proses deployment selesai untuk menghindari hal-hal yang tidak kita inginkan misalnya, kerusakan data user, kegagalan transaksi, dsb.
Support System
Dari pengalaman, sistem pendukung untuk sebuah social game yang paling penting adalah Web admin sebagai alat untuk administrasi game secara keseluruhan. Web admin mencakup:
Level & map editor
Pengaturan virtual economy dan currency
Manajemen special event, gift, rewards, announcements, promosi, diskon, dsb
Manajemen aset grafis, animasi, sound, dan video
Analytics, logging & reporting
Selain web admin, kita juga sediakan user forum di mana user bisa melaporkan bug atau masalah yang mereka alami. User forum juga bisa kita gunakan untuk mengumumkan jadwal update/ deployment. Forum sebaiknya kita tempatkan di server tersendiri biar ga mempengaruhi game. Karena forum bukan termasuk fitur yang vital, kita bisa pakai shared-hosting untuk menekan biaya.
Komitmen
Hal terakhir yang mempengaruhi kesuksesan proyek social game kita adalah komitmen dari semua orang yang terlibat bukan hanya tim programer saja, tetapi termasuk project owner / client. Utamanya komitmen untuk berkolaborasi dan berkomunikasi melalui jalur yang sudah disepakati. Ga jarang ada orang yang lebih suka berdiskusi lewat email atau lebih parah lagi, BBM, SMS, padahal semua sudah sepakat menggunakan project management software. Atau mungkin mereka ga responsif terhadap diskusi-diskusi yang ada. Ini juga perlu kita jelaskan & tegaskan di awal.
Karena faktor komitmen sangat penting, hampir mustahil mengembangkan social game dengan tim yang seluruhnya bekerja part-time. Kita butuh tim yang sebagian besar personilnya bekerja full-time.
Estimasi Biaya
Setelah kita paham apa saja yang dibutuhkan dari materi di atas, kita sampai di pertanyaan “Berapa biayanya?”. Berikut ini estimasi biaya yang saya buat berdasarkan pengalaman tapi dengan fee disesuaikan dengan rate programer lokal.
Kesimpulan
Jadi kesimpulannya, social game “sederhana” itu ga ada. Kecuali, sekali lagi, yang ingin kita buat adalah game yang sekedar “nongol”. Kalo itu sih, ga perlu repot. Langsung coding, upload, beres.
Walaupun sedikit terlambat, beberapa tahun terakhir mulai banyak perusahaan lokal yang tertarik untuk membuat aplikasi atau game, baik untuk menghasilkan income ataupun untuk membantu pemasaran produk/brand (adver-games). Sayangnya karena ketidakpahaman atau keterbatasan informasi mengenai proses pembuatan social game, banyak orang yang mengira bahwa proses pembuatan social game sama dengan pembuatan mini games. Keterbatasan informasi ini bisa dimaklumi karena setahu saya ga banyak developer yang mempublikasikan proses yang mereka jalani dalam membuat social game.
Dalam artikel ini, saya akan sedikit menjelaskan proses pembuatan social game (facebook) berdasarkan pengalaman saya di Playdom dan Hands On Entertainment. Selain untuk Anda yang ingin tahu proses pembuatan social/online game, artikel ini juga saya tujukan untuk membantu developer yang ingin melakukan pitching atau mengedukasi calon klien supaya ga ada yang bilang,
Buat game yang sederhana aja, seperti Farm Ville gitu.
Sebagai catatan, artikel ini mengacu pada pembuatan game yang dimaksudkan untuk bertahan dalam jangka panjang, bukan game sesaat yang sekedar nongol terus dibiarin mati dan saya ga membahas proses perancangan sebuah game karena proses ini terlalu spesifik.
Perencanaan
Tahap pertama dari setiap proyek, game atau bukan adalah perencanaan. Perencanaan yang baik akan mempermudah kita memperoleh hasil akhir yang baik. Sebaliknya, perencanaan yang asal-asalan akan memberi kita hasil yang juga asal-asalan.
Fail to plan, plan to fail
Ungkapan di atas adalah ungkapan populer dalam dunia pemrograman yang artinya “gagal berencana sama dengan berencana untuk gagal”. Ini untuk memperingatkan programer pemula yang seringkali terburu-buru menulis kode tanpa perencanaan. Ungkapan ini berlaku dalam semua jenis proyek, apapun bidangnya, IT maupun non-IT.
Perencanaan yang saya maksud di sini bukan hanya perencanaan (desain) game, tetapi juga perencanaan eksekusi proyek. Saya sering bertemu klien atau calon klien yang dalam perencanaannya hanya fokus pada produk akhir dan ga memperhitungkan faktor-faktor pendukung lainnya seperti infrastruktur, komunikasi, manajemen proyek, dan lain-lain. Parahnya lagi, sebagian dari mereka ternyata ga begitu peduli dengan faktor-faktor tersebut, khususnya masalah komunikasi dan manajemen proyek, yang penting mereka sediain duit & maunya tau beres. Menghadapi klien seperti ini, saya selalu menegaskan bahwa semua orang yang terlibat bertanggungjawab atas keberhasilan dan kegagalan proyek, termasuk mereka juga.
Apa saja yang perlu kita rencanakan sebelum memulai proyek?
- Infrastruktur ( Server, version control system, project management software )
- Metodologi
- Tahap-tahap development
- Deployment
- Support System
- Server
Adalah kesalahan fatal kalo kita menggunakan server minimalis kecuali untuk keperluan development dan testing. Memang infrastruktur adalah komponen biaya yang ga kecil, tapi kalo kita memang serius dan ingin game buatan kita dimainkan banyak orang, kita harus menyiapkan infrastruktur yang solid. Sebagai contoh, untuk game yang dimainkan oleh puluhan bahkan mungkin ratusan juta orang termasuk saya dan Anda juga, Zynga menyiapkan data-center yang berisi lebih dari 1000 (seribu) server yang terbagi dalam beberapa kelompok : application server, game server, database server, content-delivery dan lain-lain.
Bukan berarti kita wajib memiliki data-center seperti Zynga, tapi maksud saya adalah, kita perlu menyediakan infrastruktur terutama server sesuai dengan target DAU (daily active users) atau CCU (concurrently connected users) jika kita akan membuat game realtime multi-player.
Kita perlu menyiapkan minimal 3 server yaitu:
- Development Server
- Staging Server
- Production (live) server
Server
Development Server kita gunakan selama proses development. Server ini boleh (dan harus) diutak-atik programer setiap hari. Server ini berfungsi sebagai sandbox di mana programer melakukan testing dan deployment setiap saat.
Staging Server kita gunakan untuk keperluan testing/quality control sebelum kita melakukan release ke live server.
Production/Live Server adalah server yang diakses oleh publik/user.
Semua server bisa terpisah secara fisik (dedicated) atau virtual. Paling baik, untuk live server kita sewa dedicated server tapi untuk menghemat biaya, dalam banyak kasus di mana DAU ga terlalu besar, VPS (virtual private server) di mana kita berbagi pakai sebuah unit komputer server dengan orang lain sudah cukup baik. Shared-hosting dengan biaya murah sebaiknya dihindari karena banyak provider yang menjejalkan terlalu banyak user dalam satu unit komputer (oversell) sehingga akan mempengaruhi performance game kita. Untuk keperluan development dan testing, kita ga perlu dedicated server karena VPS sudah lebih dari cukup.
Kita bisa mulai proyek dengan satu VPS yang kita gunakan untuk keperluan development dan testing. Namun sebaiknya kita punya minimal dua VPS, satu untuk development, satu untuk staging (testing). Kenapa server development dan staging perlu terpisah? Tujuannya adalah agar kita bisa melakukan testing dalam kondisi terisolasi dan ga terpengaruh faktor lain. Development server adalah server yang setiap hari diutak-atik oleh programer dan ada kemungkinan mereka menyebabkan server crash, memory leak, dan lain-lain yang akhirnya mempengaruhi proses staging jika kedua server ga terisolasi.
Faktor berikutnya adalah lokasi server. Kita perlu memilih lokasi server yang terdekat dengan target pasar/konsumen. Untuk konsumen lokal, kita bisa menggunakan server yang ada di Jakarta atau Singapura.
Berikut ini beberapa provider yang bisa saya rekomendasikan:
Linode . VPS dengan salah satu data-center di Singapura.
Webfaction. Shared-hosting dengan performance dan fitur setara VPS. Salah satu data center ada di Singapura.
Futurehosting. VPS atau dedicated server. Data center di Amerika.
WiredTree. VPS atau dedicated server. Data center di Amerika.
Saya ga merekomendasikan produk Amazon selain Amazon S3 (content-delivery) karena struktur harganya yang membingungkan dan pada akhirnya biaya yang kita keluarkan juga lebih tinggi daripada kalo kita menggunakan jasa hosting yang lain.
Anda juga bisa window-shopping di forum Webhostingtalk untuk melihat tawaran-tawaran hosting dari berbagai provider di seluruh dunia.
Version Control & Code repository
Selain server untuk game dan aplikasi pendukungnya, kita perlu menyiapkan apa yang disebut version control yang digunakan oleh programer untuk berkolaborasi dan menyimpan source code. Dengan menggunakan repositori, programer ga perlu melakukan upload secara manual ke development, staging, ataupun live server sehingga akan menghemat waktu dan juga meminimalkan konflik.
Kalo Anda ga pernah dengar istilah version control, silakan baca ebook yang saya tulis berjudul Mengenal Git.
Kalo Anda mau, Anda bisa membuat repositori di server Anda sendiri. Tapi menurut saya lebih enak kalo kita menggunakan jasa repository hosting seperti Beanstalk, Github, atau Bitbucket. Ga perlu repot instal dan maintenance. Plus mereka menyediakan banyak fitur yang semakin mempermudah pekerjaan kita seperti automated-deployment, commit hooks, dan lain-lain.
Komunikasi & Project Management
Salah satu hal yang sering dilupakan adalah bagaimana cara kita berkomunikasi. Dari pengalaman, saya bisa pastikan email saja ga cukup untuk berkomunikasi, terutama kalo banyak orang yang terlibat. Kita butuh sarana yang memungkinkan kita untuk :
Mengelompokkan diskusi berdasarkan topik atau bagian. Misalnya, diskusi tentang perencanaan kita kelompokkan dalam grup “Planning”, laporan bug kita kelompokkan dalam grup “Bug”, masalah server dalam grup “Server”, dan sebagainya.
Mengambil web link sebuah diskusi atau komentar untuk keperluan referensi. Misalnya, klien menulis komentar dalam thread diskusi B, kita bisa dengan mudah mem-bookmark komentar ini dan membagikannya.
Memastikan semua orang membaca sebuah diskusi minimal mendapat notifikasi. Berapa kali kita lupa cc saat menulis email?
Membaca thread yang panjang ga pake pusing dan sakit mata. Saya ga tahu bagaimana dengan Anda, tapi thread email yang panjang sering bikin saya pusing. Apalagi kalo posting-nya ga berurutan, bisa mual dan nggreges.
Banyak proyek yang gagal hanya karena masalah komunikasi. Jadi, kita ga boleh menganggap remeh masalah ini.
Untuk mempermudah komunikasi, kita bisa menggunakan project management software. Kita bisa pilih software online atau offline sesuai kebutuhan. Project Management Software menyediakan banyak fitur seperti forum diskusi, kumpulan catatan/referensi baik berupa teks atau file, berbagi pakai dokumen, penjadwalan, dan sebagainya. Bebeapa provider juga menyediakan version control dalam paket-paketnya. Berikut ini beberapa layanan online yang saya rekomendasikan:
- Teamworkpm
- Jira
- Assembla
- Goplan
- Basecamp
- Kalau Anda punya waktu dan personil yang cukup (dan mau repot instalasi & maintenance), Anda bisa pakai software open-source seperti:
- Trac
- Streber
- Project Pier
- Metodologi
Ada dua metodologi dalam pengembangan software yaitu:
Waterfall
Agile
Waterfall adalah metodologi klasik yang sudah bertahun-tahun diterapkan dalam industri software. Dalam metodologi ini, kita berusaha membuat rencana (spesifikasi) yang sesempurna mungkin sebelum proyek dijalankan. Karena dibuat di depan, rencana kita bersifat kaku dan hampir bisa dipastikan perubahan rencana di tengah jalan akan menyebabkan proyek mundur atau menyebabkan biaya (cost) tinggi. Namun begitu, metodologi ini masih tetap populer karena mudah dijalankan dan ga membutuhkan skill khusus.
Metode modern yang mulai populer pada awal tahun 2000-an disebut Agile Methodology. Metode ini terinspirasi dari industri otomotif di Jepang yang sangat efisien dan produktif jika dibandingkan dengan industri serupa di Eropa dan Amerika. Dalam metodologi ini, kita membuat perencanaan secukupnya sebelum proyek dimulai. Proyek dibagi dalam beberapa siklus singkat (2 – 4 minggu) yang disebut sprint di mana setiap sprint diawali dengan planning diakhiri dengan release.
Metode Agile terbukti sangat fleksibel dan memungkinkan kita mengubah spesifikasi di tengah jalan dengan biaya (cost) minimal. Agar dapat menjalankan metode ini, kita membutuhkan programer yang kompeten dan berpengalaman dalam membuat arsitektur yang fleksibel. Mencari programer seperti ini bukan perkara mudah. Banyak programer yang sudah berpengalaman tapi ga bisa membuat arsitektur yang fleksibel, kode yang mereka tulis ga fleksibel sehingga sulit untuk diubah di tengah jalan. Programer yang kita cari adalah programer yang ga hanya bisa menulis kode tetapi juga mengerti kelebihan dan kekurangan bahasa yang mereka gunakan serta, utamanya, mengerti apa yang disebut Design Patterns dan tahu cara membuat framework juga terbiasa mempraktekkan best-practices. Bukan berarti semua programer dalam tim kita harus sekaliber ini, minimal kita punya satu atau dua orang yang mumpuni dan bisa menjadi mentor programer lain yang skill-nya di bawah mereka.
Perbedaan lain yang cukup signifikan antara agile dan waterfall adalah release target. Dalam metodologi Agile, release dilakukan secara berkala dan dalam fase-fase awal, targetnya adalah minimum viable product yaitu produk dengan fitur minimal tetapi sudah bisa digunakan. Sementara dalam metodologi waterfall targetnya adalah complete product. Tim yang menggunakan metodologi agile bisa melakukan release lebih cepat dan lebih sering daripada tim yang menggunakan metodologi waterfall walaupun hasil akhirnya nanti juga sama.
Ada dua implementasi metodologi Agile yang banyak dipraktekkan dalam industri software yaitu:
Scrum
Kanban
Metode Agile ga mungkin dijelaskan dalam artikel ini tapi saya berencana menulis artikel khusus mengenai Scrum di lain waktu berdasarkan pengalaman saya bekerja di Hands On Entertainment. Untuk sementara, kalo Anda tertarik silakan tanya Oom Google.
Satu hal lagi, sebelum kita memulai proyek ada baiknya kita tulis dalam proposal metode apa yang akan kita pakai sehingga orang-orang yang terlibat bisa membayangkan seperti apa siklus proyek nantinya. Ga masalah metode mana yang kita pilih, asalkan kita siap dengan konsekuensinya dan bisa mengantisipasi perubahan-perubahan di tengah jalan.
Hal lain yang perlu dijelaskan di awal adalah:
Peran setiap orang. Siapa yang bertanggung jawab membuat framework, siapa yang menangani proses release, dan sebagainya. Satu peran bisa dijalankan oleh beberapa orang. Satu orang bisa menangani beberapa peran.
Quality control. Bagaimana menjamin kode yang ditulis satu orang ga menimbulkan konflik dengan kode yang ditulis orang lain? Apa kita akan mengadakan code review? Dan sebagainya.
Standar penulisan kode. Di sini kita menentukan format penulisan kode dengan tujuan agar kode yang ditulis oleh seseorang bisa dipahami dan dilanjutkan oleh orang lain.
Perencanaan
Kecuali kita menyewa paranormal seperti Ki Joko Bodo, ga mungkin kita membuat rencana yang benar-benar solid dan akurat. Dalam dunia pemrograman ada ungkapan berikut.
The only constant is change
Artinya, satu-satunya hal yang pasti dalam pembuatan software adalah perubahan. Maksudnya, ga peduli sebagus apa rencana yang kita buat, pasti di tengah jalan kita harus melakukan perubahan. Karena itu, proses perencanaan ga akan pernah berhenti. Perencanaan dan perubahan rencana harus didiskusikan dan didokumentasikan secara baik sehingga bisa dijadikan referensi.
Untuk proyek game, umumnya ada dua dokumen penting yang harus dibaca semua orang yaitu:
Game Design Document (GDD). Berisi rancangan game, target pasar, monetization, cara memainkannya, unsur-unsur challenge, rewards, grafis, animasi, dsb.
Technical Design Document (TDD). Berisi rancangan teknis antara lain berapa server yang digunakan & sistem operasinya, metode deployment, koneksi dengan version control system, format data, dsb.
Development
Proses development ga hanya menyangkut pemrograman tetapi juga pembuatan aset grafis, animasi, dan sebagainya. Termasuk dalam proses ini adalah internal testing yang dilakukan oleh tim programer. Selama proses ini sebaiknya para programer ga “diganggu” dengan permintaan yang bermacam-macam baik oleh project manager ataupun klien. Semua permintaan/rekues harus diberi bobot prioritas, yang ga berprioritas tinggi dan bisa ditunda sebaiknya ditunda sampai tim programer selesai mengerjakan task yang sedang mereka tangani.
Proses development pada dasarnya terbagi dalam dua macam yaitu feature addition dan bug fixing.
Feature Addition
Dalam proses ini, tim programer menambahkan fitur baru ke dalam game. Fitur-fitur yang akan ditambahkan perlu dikelompokkan berdasarkan:
Prioritas
Dependency (ketergantungan) karena mungkin saja sebuah fitur baru bisa ditambahkan kalo fitur lain sudah ada.
Tim programer dan project manager akan menyusun jadwal berdasarkan kedua faktor di atas.
Bug-fixing
Setiap bug yang dilaporkan akan ditangani tim programer berdasarkan prioritasnya. Setelah bug diperbaiki, tim programer bertanggungjawab untuk memberitahu pembuat bug report bahwa bug bisa diuji kembali pada fase staging berikutnya. Jadi, tim programer wajib menyediakan daftar bug yang udah dibenerin & siap dites lagi.
Bug-fixing harus lebih diutamakan daripada feature addition.
Staging (Testing/QC)
Ketika tim programer menyelesaikan sejumlah task dan game bisa diuji, mereka atau orang yang ditunjuk akan melakukan proses yang melakukan upload atau deployment kode dan segala aset pendukungnya ke staging server. Game selanjutnya diuji oleh tim penguji (tester). Proses ini ditujukan untuk quality control yaitu menguji produk sebelum dilepas ke publik (live server).
Pengujian sebaiknya dilakukan oleh orang-orang di luar tim programer karena beberapa alasan:
Orang di luar tim developer bisa menguji produk dengan lebih obyektif
Tim developer terbiasa menguji produk dengan cara dan urutan yang sama berulangkali. Orang lain menguji produk dengan urutan dan cara yang acak sehingga bisa menemukan bug yang mungkin terlewatkan oleh developer.
Orang di luar tim developer mungkin menggunakan Sistem Operasi dan browser yang berbeda-beda sehingga bisa menemukan isu atau masalah kompatibilitas.
Tim programer hampir pasti ga punya waktu untuk melakukan pengujian menyeluruh dan mengkover bermacam-macam skenario (OS, browser, urutan aksi).
Bug yang ditemukan selama pengujian harus didokumentasikan. Proses ini makan waktu juga.
Dokumentasi Bug
Sebelum melakukan testing, tim penguji perlu dibekali dengan pengetahuan tentang cara menguji dan mendokumentasikan bug. Beberapa aturan umum yang sering dipraktekkan :
Waktu melakukan pengujian, sistem/komputer si penguji harus bebas dari proses/program lain yang mungkin mempengaruhi pengujian. Misalnya:
background process bisa mempengaruhi performa game yang diuji jadi jangan menguji game sambil browsing atau nonton Youtube
browser plugin/extension yang ga perlu harus dinonaktifkan
Sebuah masalah baru bisa disebut bug kalo bisa direproduksi/diulangi oleh si penguji. Kalau si penguji ga bisa mengulangi bug, apalagi tim programer.
Tim penguji ga boleh melaporkan sebuah bug yang udah pernah dilaporkan tapi belum diperbaiki oleh tim programer supaya ga ada double-entry. Jadi sebelum membuat laporan, tim penguji harus mengecek daftar bug yang udah ada.
Dokumentasi bug yang baik berisi:
Tanggal dan waktu pengujian
Cara-cara untuk mereproduksi (mengulangi) bug tersebut
Screenshot yang memperlihatkan kondisi pada waktu bug terjadi (kalo bug bisa dilihat secara visual)
OS, Browser, dan versi plugin yang digunakan oleh penguji
Prioritas, sebagai acuan tim programer dalam melakukan scheduling
Semua bug yang didokumentasikan dikumpulkan di satu tempat dan dikelompokkan berdasarkan kategori misalnya kategori ui untuk bug yang berkaitan dengan user interface, kategori gameplay untuk bug yang berkaitan dengan game itu sendiri, dan sebagainya. Semua project management software mempermudah kita melakukan dokumentasi, pengumpulan, dan pengelompokkan bug reports bahkan memungkinkan kita mengkonversi bug report menjadi task.
Salah satu penyakit yang sering bikin jengkel adalah tim penguji yang berulangkali melaporkan bug yang sama padahal bug itu memang belum kita benerin atau mereka seenaknya memberi prioritas tinggi pada semua bug tidak peduli apa bug itu benar-benar krusial atau ga. Di sini peran project manager atau lead programmer sangat penting untuk memfilter laporan-laporan yang ga perlu.
Deployment/Release
Deployment
Setelah tim programer menyelesaikan beberapa task (tugas), mereka melakukan deployment ke staging server. Proses deployment ini juga harus dilengkapi dengan dokumentasi mengenai task mana saja yang sudah dikerjakan sehingga tim penguji bisa fokus pada task tersebut.
Kalo kita menggunakan version control, kita bisa memanfaatkan fitur tag untuk menandai commit atau update terakhir yang disertakan dalam staging. Contohnya, kita bisa memberi tag “staging 01 Januari 2013”, “staging 20 Januari 2013”, “release 10 Februari 2013”, dan sebagainya.
Kalo dalam proses staging tidak ditemukan bug yang fatal (menyebabkan error kelas berat, seperti crash, hang, dsb), berikutnya kita bisa melakukan release ke live server. Sama dengan proses staging, tim programer juga perlu menandai update terakhir yang disertakan dalam proses release. Kenapa? Supaya kalo terjadi apa-apa, ada error dsb, kita mudah melakukan rollback (kembali ke versi release sebelumnya).
Version control hosting biasanya menyediakan sarana untuk melakukan deployment melalui web interface dan deployment yang dilakukan otomatis dicatat oleh sistem sehingga kita mudah melakukan rollback.
Sebaiknya kita menginformasikan rencana deployment kepada user dan tim penguji. Lebih baik lagi kalo kita sementara menon-aktifkan game sampai proses deployment selesai untuk menghindari hal-hal yang tidak kita inginkan misalnya, kerusakan data user, kegagalan transaksi, dsb.
Support System
Dari pengalaman, sistem pendukung untuk sebuah social game yang paling penting adalah Web admin sebagai alat untuk administrasi game secara keseluruhan. Web admin mencakup:
Level & map editor
Pengaturan virtual economy dan currency
Manajemen special event, gift, rewards, announcements, promosi, diskon, dsb
Manajemen aset grafis, animasi, sound, dan video
Analytics, logging & reporting
Selain web admin, kita juga sediakan user forum di mana user bisa melaporkan bug atau masalah yang mereka alami. User forum juga bisa kita gunakan untuk mengumumkan jadwal update/ deployment. Forum sebaiknya kita tempatkan di server tersendiri biar ga mempengaruhi game. Karena forum bukan termasuk fitur yang vital, kita bisa pakai shared-hosting untuk menekan biaya.
Komitmen
Hal terakhir yang mempengaruhi kesuksesan proyek social game kita adalah komitmen dari semua orang yang terlibat bukan hanya tim programer saja, tetapi termasuk project owner / client. Utamanya komitmen untuk berkolaborasi dan berkomunikasi melalui jalur yang sudah disepakati. Ga jarang ada orang yang lebih suka berdiskusi lewat email atau lebih parah lagi, BBM, SMS, padahal semua sudah sepakat menggunakan project management software. Atau mungkin mereka ga responsif terhadap diskusi-diskusi yang ada. Ini juga perlu kita jelaskan & tegaskan di awal.
Karena faktor komitmen sangat penting, hampir mustahil mengembangkan social game dengan tim yang seluruhnya bekerja part-time. Kita butuh tim yang sebagian besar personilnya bekerja full-time.
Estimasi Biaya
Setelah kita paham apa saja yang dibutuhkan dari materi di atas, kita sampai di pertanyaan “Berapa biayanya?”. Berikut ini estimasi biaya yang saya buat berdasarkan pengalaman tapi dengan fee disesuaikan dengan rate programer lokal.
Kesimpulan
Jadi kesimpulannya, social game “sederhana” itu ga ada. Kecuali, sekali lagi, yang ingin kita buat adalah game yang sekedar “nongol”. Kalo itu sih, ga perlu repot. Langsung coding, upload, beres.
- MESIN PENCETAK UANG 2013 KLIK DISINI
- JANGN DIKLIK ( KUSUS DEWASA )
Tidak ada komentar:
Posting Komentar