Pelajaran yang bisa dipetik dari game Factorio bagi Software Engineer

Pelajaran yang bisa dipetik dari game Factorio bagi Software Engineer

Banyak yang bilang Factorio adalah game yang wajib dimainkan oleh Software Engineer . Bahkan Shopify membolehkan karyawannya untuk reimburse pembelian pribadi untuk game ini. Inilah beberapa pelajaran yang saya peroleh setelah bermain game ini.

Game macam apa sebenarnya Factorio?

Factorio on Steam
Factorio is a game about building and creating automated factories to produce items of increasing complexity, within an infinite 2D world. Use your imagination to design your factory, combine simple elements into ingenious structures, and finally protect it from the creatures who don’t really like you.

Premis bermain Factorio cukup sederhana: kamu terdampar di sebuah planet tak bertuan. Roketmu hancur berantakan. Tugasmu adalah membuat roket kembali untuk diluncurkan ke luar angkasa. Untuk mencapai teknologi roket kamu perlu membangun dan riset dari nol. Mulai dari mengolah bahan mentah seperti bijih besi dan tembaga, hingga berhasil membuat low density material (structure).

Mengapa Factorio bisa terhubung dengan software engineer? Inti dari game ini sebenarnya adalah problem solving dan automation. Kedua hal ini adalah makanan sehari-hari bagi software engineer, jadi seringkali problem yang ada di game berhubungan dengan pekerjaan.

Bayangkan sebuah Website

Sebelum membaca, mari kita berandai-andai menjadi seorang full-stack engineer yang bertugas mengelola sebuah website. Untuk menyelaraskan istilah, kita ibaratkan website ini layaknya sebuah pabrik. Setiap pabrik mempunyai input, processing, dan output. Dalam manufaktur, input adalah bahan mentah, sedangkan output adalah barang jadi.

Jika diterjemahkan ke istilah website, input diterima dari user. Bisa berarti visit, menambahkan item ke keranjang belanja, dan lain-lain. Website memroses input dari user. Output yang dihasilkan berupa data ke user, misalnya dalam bentuk invoice atau sekedar artikel berita.

Di poin-poin berikut ini saya akan memberikan ilustrasi seperti di atas dan menerjemahkannya ke dalam game Factorio. Begitu pula sebaliknya.

Belajar Scaling Up

Dalam bermain Factorio, kalian akan berhadapan dengan berbagai masalah. Tidak ada cara yang benar ataupun salah selama kalian berhasil memecahkan masalah tersebut. Dan seperti di dunia nyata, setiap solusi ada pros dan cons-nya. Masalah pertama yang akan kalian hadapi adalah "bagaimana menghasilkan X".

Perhatikan ilustrasi di bawah ini:

FIG1: Sebuah Steel Smelter sederhana

Ini adalah pabrik pembuat baja (Steel) yang sederhana. Sebatang baja dibuat dari 5 lempeng besi (Iron Plate). Lempeng besi dibuat dari sebuah bijih besi (Iron ore). Dan untuk mengaktifkan tungku diperlukan batubara (Coal) sebagai bahan bakarnya.

Itu adalah solusi sederhana untuk "bagainana menghasilkan sebatang baja". Namun solusi ini menghasilkan sebatang baja dalam 16 detik. Ibaratnya, website kamu hanya mampun dikunjungi oleh 10 request per menit, misalnya. Bagaimana cara meningkatkan outputnya? Horizontal dan Vertical scaling, sangat familiar bagi software engineer.

Ini adalah contoh horizontal scaling. Pada dasarnya adalah meningkatkan jumlah tungkunya. Namun untuk tungku tersebut membutuhkan suplai batubara dan bijih besi, jadi materialnya dibawa menggunakan ban berjalan. Ini adalah cara memecahkannya di Factorio. Dalam software engineering, ini artinya menambah jumlah server. Tungku ini ibaratnya sebagai server. User traffic mesti dibagi ke setiap server, sehingga ban berjalan ini ibaratnya sebagai load balancer.

FIG2: Steel Smelter yang mudah di scaling

Kita bisa membuat lini produksi seperti di atas, namun tidak ada patokan skema tertentu di Factorio. Player bebas membentuk pabrik seperti apapun. Inilah mengapa kreativitas pemain di Factorio diuji, ini bisa melatih kreativitas kalian sebagai software engineer untuk tidak hanya melihat sebuah solusi saja.

Salah satu keunggulan lini produksi ini adalah kemudahannya untuk ekspansi. Saya cukup meng-copy dua baris tungku seperti di bawah ini untuk mem-provision lini berikutnya. Mirip seperti deploying server πŸ˜„.

FIG3: Copy & paste pola serupa

Masalah yang muncul dari lini produksi di atas adalah adalah berkurangnya input bahan mentah, penyebabnya adalah processor-nya semakin banyak. Output > Input. Ini artinya kanal inputnya harus dilebarkan. Salah satunya adalah dengan meningkatkan arus input dengan meng-upgrade ban berjalan yang lebih cepat (FIG4). Dalam software engineering, ini bisa berarti kita memesan bandwidth yang lebih besar dari perusahaan hosting. Untuk Cloud hosting, tentunya ini sudah termasuk ke dalam biaya penggunaan, ya πŸ’Έ.

FIG4: Low bandwidth problem, upgrade Yellow Belt -> Red Belt

Overengineering

Bayangkan suatu hari tim marketing membutuhkan bantuan ke software engineer untuk membuat sebuah landing page (bukan kisah nyata). Usai mengerjakan, software engineer ini berinisiatif untuk membuatkan Content Management System untuk landing page. Harapannya kalau ada permintaan lagi, mereka bisa buat sendiri dan tidak perlu dukungan software engineer.

Nyatanya, tim marketing tidak pernah lagi membuat permintaan untuk landing page. Setelah diusut, ternyata hasil uji coba yang pertama tidak sesuai harapan (sekali lagi bukan kisah nyata). CMS ini pun akhirnya tidak digunakan. Kisah ini juga kalian bisa temui di Factorio, perhatikan 5 peti berikut ini:

FIG5: Iron Chest membutuhkan 8 Iron Plate

Untuk membuat satu peti membutuhkan waktu singkat, setengah detik saja. Dengan harapan bahwa peti akan banyak dibutuhkan, kita bisa membuat lini produksi khusus untuk membuat peti seperti di bawah ini. Hanya saja material di Factorio itu terbatas, jadi kita meminjam material dari lini produksi yang sudah ada. Dengan sedikitnya suplai lempeng besi untuk peti ini, produksi peti tidak dapat dihasilkan. Ibarat di dunia nyata, kita meminjam waktu untuk mengerjakan proyek CMS. Perhatikan bagan perhitungan di bawah ini:

Di Factorio kalian akan sering menjumpai ban berjalan yang "ompong" karena kekurangan material. Tak jarang pemain Factorio akan menghitung-hitung output dari sebuah lini produksi secara manual. Pada bagan di atas saya menghitung ternyata kita kekurangan 15 lempeng besi per detik. Artinya produksi peti tidak akan mendapatkan material yang dibutuhkan. Lebih cepat merangkai Peti sendiri daripada harus menunggu material dari lini produksi ini.

Pelajaran dari kasus di atas adalah overengineering sering ditemukan jika utilisasi rendah. Membuatkan sebuah otomasi untuk sesuatu yang tidak memberikan nilai tambah atau tidak lebih baik dari sistem yang sudah ada. Menyebabkan cost yang tidak perlu.

Underengineering

Kebalikan dari kasus sebelumnya, untuk kasus berikut ini software engineer bisa menjadi bottleneck-nya.

Bayangkan rikues serupa (landing page), namun tim marketing secara rutin meminta bantuan setiap minggunya. Utilisasi dijamin tinggi. Alhasil, setiap minggu bakalan ada pengerjaan landing page, yang awalnya permintaan sesekali kini menjadi tugas yang rutin. Akhirnya waktu untuk development project lain menjadi berkurang. Untuk kasus ini, keberadaan CMS justru sangat membantu. Keterlambatan memahami situasi ini menyebabkan waktu si software engineer terbuang percuma. Sama halnya di Factorio, sebagai contoh untuk produksi Utility science pack berikut ini:

FIG7: Sebuah komponen yang bisa dibuat sendiri

Bagan di atas adalah bagan untuk memproduksi sebuah komponen sains. Di Factorio komponen sains ini dibutuhkan untuk meriset teknologi, dengan kata lain ini adalah mata uang untuk menghasilkan teknologi. Player bisa membuatnya sendiri tanpa harus melalui assembler. Dalam semenit player bisa menghasilkan 0,62 dari komponen tersebut. Masalahnya, game ini membutuhkan player untuk menghasilkan ratusan komponen ini πŸ˜‚, kita bisa saja membuatnya secara manual namun butuh waktu puluhan jam di dunia nyata.

Bandingkan dengan lini produksi berikut yang sudah dioptimasi dengan speed module. Kini kita bisa menghasilkan 19.2 komponen per menit. Belasan kali lipat lebih cepat dari crafting sendiri.

FIG8: Komponen yang sama dibuat dengan otomasi

Dari sini kita belajar pentingnya untuk mencari tahu lebih dalam kebutuhan dari stakeholder. Berusaha memahami domain dari pekerjaan akan membantu kita untuk membuat estimasi dan rancangan solusi yang lebih baik.

Do it Right, then Do it Fast

Berkaitan dengan scaling up, di Factorio penting untuk merancang lini produksi yang efisien. Layout yang tidak rapi dan kecil akan memakan banyak tempat. Tempat yang bisa digunakan untuk menambahkan sebuah lini produksi lainnya. Sehingga penting untuk merancang dengan benar terlebih dahulu sebelum ekspansi lebih lanjut.

Sama halnya ketika kita menambah jumlah server. Sebisa mungkin server yang kita provision itu dibangun dari operating system yang bersih dari software tambahan. Selain untuk menghemat storage, juga untuk menghemat bandwidth ketika container mengunduh image yang sering kita gunakan.

Dari ilustrasi di bawah, dengan ruang terbatas kita berhasil menambahkan 14 assembler, meningkatkan output menjadi 268.8 per menit.

FIG9: Sebuah lini produksi yang scalable

Pentingnya Monitoring dan Observability

Monitoring di Factorio itu sangat penting, lengah sedikit bisa langsung menemui masalah berikut:

FIG10: Kurang energi, lumrah terjadi

Di Factorio kita bisa melihat output energi yang dikeluarkan beserta kebutuhannya. Jika Demand lebih besar dari Suplai, maka di beberapa area akan muncul indikator merah seperti di atas. Namun apabila suplai energi bergantung pada panel tenaga surya, maka suplai energi bisa mati total begitu cadangan batere sudah habis:

FIG11: "Mati lampu"

Di dalam cloud hosting biasanya sudah ada monitoring. Pemakaian CPU, Memory, dan I/O lumrah tersedia. Sudah menjadi pengetahuan umum juga jika metriks di atas tidak cukup untuk menjelaskan apabila website tiba-tiba down. Metriks tambahan misalnya dengan menambahkan error monitoring seperti Sentry atau metriks tambahan lainnya dengan Grafana.

Di Factorio kita juga bisa menambahkan instrumen tambahan untuk meningkatkan observability, dalam hal ini kita bisa memonitoring apa saja yang dibawa oleh ban berjalan dengan Display Panel berikut ini:

FIG12: memonitor jumlah uranium di atas ban berjalan

Kamu bisa mengatur logika yang dipakai untuk memunculkan pesan berdasarkan kondisi tertentu. Misalnya dengan memunculkan pesan β€œLow uranium” apabila konten di atas ban berjalan kurang dari 4 buah.

Seringkali software engineer bertindak layaknya detektif. Kemampuan investigatif ini juga banyak dilatih di Factorio. Pada contoh kasus ini, ternyata penyebab berkurangnya suplai uranium adalah akibat kereta yang macet πŸ˜„. Setelah ditelusuri, ternyata ada kereta yang menghalangi jalur tersebut sehingga sinyalnya terindikasi merah β€œno-go”. Saya bisa menjelaskan sendiri mengenai sistem kereta api ini dalam artikel terpisah, namun untuk menyederhanakan solusi ini, saya cukup menjalankan kereta secara manual untuk membebaskan jalur kereta uranium ini. Problem solved!

FIG13: Kereta uranium mandek karena ada objek menghalangi. Root cause: jalur kereta tidak dapat mengakomodir alur dari dua arah

Kesimpulan

Factorio adalah sebuah game yang sangat erat kaitannya dengan profesi sebagai software engineer. Dari luar game ini terlihat seperti resource management biasa namun di dalamnya adalah permainan problem solving yang berulang dan membebaskan pemainnya memecahkan masalah dengan kreatif. Tidak ada solusi yang paling benar, semuanya bisa diukur, dipantau, serta dibuatkan otomasinya. Ini adalah game yang sangat menyenangkan apabila problem solving adalah aktivitas yang kamu sukai.

Read more

Mastodon