Tramway SDK – Gabungan sesat antara mesin Half-Life dan Morrowind

• Tramway SDK adalah paket grafis/framework/game engine yang dikembangkan selama 3 tahun terakhir, dengan tujuan menjadi engine ringan yang menentang kebutuhan spesifikasi tinggi dan alur editor monolitik dari engine arus utama
• Menilai bahwa engine arus utama seperti Unity dan Godot menuntut hardware berlebihan bahkan untuk game low-poly sederhana, target eksekusinya mencakup hardware dari 15 tahun terakhir hingga rasterisasi perangkat lunak
• Alih-alih bolak-balik antara GUI node dan kode, cara pembuatannya menggunakan pewarisan kelas Entity untuk menulis kode, dengan struktur yang memungkinkan hanya editor yang diperlukan saja yang dipakai
• Pembuatan level berbasis workflow brush ala Quake, memanfaatkan konverter .map, lightmap, shading Gouraud, dan sistem input/output ala Source
• Menargetkan open-world streaming dan framework RPG yang lebih dekat ke 3D RPG Maker, tetapi karena masih tahap pengembangan awal, API yang belum stabil dan elemen yang belum diimplementasikan perlu diperhitungkan

---

Masalah yang ingin dipecahkan Tramway SDK

• Tramway SDK adalah paket grafis, framework, dan game engine, serta juga memakai penulisan bergaya heavy metal “T̈ra̦m̊ẅa̦ÿ SD̈K”
• Kritik terhadap engine arus utama berfokus pada Turbobloat
  • Unity dianggap membutuhkan hardware yang sangat kuat dan daya yang besar
  • Godot dinilai sedikit lebih baik daripada Unity, tetapi tetap memerlukan hardware yang relatif mumpuni
  • Game seperti low-poly horror roguelite deckbuilder simulator seharusnya tetap bisa berjalan dengan baik di hardware berusia 15 tahun
• Tramway SDK mengklaim dapat berjalan di hampir semua hardware dalam 15 tahun terakhir karena tidak memiliki Turbobloat
  • Bisa beralih ke rasterisasi perangkat lunak agar tetap berjalan tanpa kartu grafis
  • Bahkan memberi contoh menampilkan grafis di perangkat seperti toaster atau kulkas
• Terhadap sanggahan “tinggal beli komputer yang lebih bagus”, mereka menanggapinya dengan tiga alasan
  • Masalah keterjangkauan, karena banyak orang tidak mampu membeli hardware kuat
  • Masalah limbah elektronik, karena produksi chip komputer buruk bagi lingkungan, dan jika software tidak membengkak maka hardware baru hanya perlu dibeli saat perangkat lama rusak dan tak bisa diperbaiki
  • Jika sudah punya komputer yang masih bekerja dengan baik, tidak ada alasan membeli komputer baru hanya karena Turbobloat buatan orang lain

Cara pembuatan dan fitur

• Metode pembuatan berbasis node dikritik karena harus menangani “banyak hal yang tampak seperti satu hal” dan memaksa perpindahan antara GUI node dan kode
• Di Tramway SDK, cukup menulis kode dengan mewarisi kelas Entity lalu membuat level di editor level
  • Tidak menggunakan node, melainkan berpusat pada entitas
  • Menghindari alur kerja bolak-balik antara kode dan GUI node
• Editor monolitik pada engine arus utama juga dianggap bermasalah
  • Pengguna harus menunggu seluruh editor dimuat, termasuk fitur yang tidak dipakai
  • Semua editor di Tramway SDK bersifat opsional
  • Jika hanya dipakai sebagai framework, pengguna bisa cukup memakai runtime C++
  • Jika hanya butuh membuat level, cukup gunakan editor level saja
  • File data memakai format nilai yang dipisahkan spasi, sehingga bisa diedit manual tanpa editor
• Dari sisi grafis, gambar contoh bisa dibuat hanya dengan lightmap dan shading Gouraud
  • Contoh tersebut bahkan bisa dirender di fixed-function pipeline kartu grafis setingkat Direct3D 7
• Pembuatan level mendukung workflow berbasis brush ala seri Quake
  • Tramway SDK menyediakan konverter file .map yang mengubah brush menjadi mesh segitiga
  • Ditunjukkan alur membuat level di Trenchbroom lalu mengatur konfigurasinya di editor level Tramway SDK
  • Level dengan lightmap diterapkan lalu dirender di dalam engine
  • Dengan sistem input/output mirip Source, interaksi antar-entitas dalam level bisa diatur
  • Ke depannya, ada rencana mengimplementasikan seluruh Source logic entity agar visual scripting bisa dilakukan di dalam editor level
• Di sisi RPG, alat seperti RPG Maker dan mod/total conversion berbasis Morrowind dipandang sebagai contoh menarik karena banyak hal bisa dibuat lewat perubahan data
  • Tramway SDK memiliki ekstensi framework RPG yang mendekati RPG Maker untuk 3D
  • Engine ini sejak awal dirancang mendukung level streaming, sehingga pembuatan game bergaya RPG open world dapat dilakukan dengan lebih cepat dan mudah
• Singkatnya, Tramway SDK adalah game engine berbasis entitas bergaya Quake/Source yang menyediakan ekstensi opsional seperti open-world streaming dan framework RPG
• Status pengembangannya masih sangat awal
  • API belum stabil
  • Fitur bisa rusak atau tidak berfungsi
  • Masih banyak elemen yang belum diimplementasikan
  • Disebut sedang ditingkatkan dengan cepat
• Repositori GitHub: racenis/tram-sdk

[GN⁺]

Pendapat Hacker News

• Mungkin ada yang berkata “beli saja komputer yang lebih bagus”, tetapi karena itulah saya sepenuhnya setuju bahwa membeli komputer yang lebih bagus itu buruk. Banyak orang, terutama di negara berkembang, tidak mampu membeli perangkat keras untuk menjalankan Turbobloat, dan produksi chip berdampak buruk terhadap lingkungan
  Jika perangkat lunak modern tidak sebegitu membengkak, orang baru akan membeli yang baru hanya ketika perangkat keras lama rusak dan tidak bisa diperbaiki. Kalau ada komputer yang masih berfungsi dengan baik, tidak ada alasan membeli komputer baru gara-gara software bengkak buatan orang lain, dan dengan uang itu bisa membeli 1000 kaleng Dr. Pepper. Ini proyek yang benar-benar bagus, jadi saya berharap mereka terus membagikan perkembangan

  • Disebut “resolusi layar dari 320x200 sampai 800x600”, tetapi resolusi yang lebih tinggi tidak diciptakan hanya karena Turbobloat
  • Meski mengatakan begitu, engine ini tampaknya membutuhkan GPU OpenGL 4, padahal grafisnya terlihat seperti sesuatu yang bisa dijalankan bahkan dengan kartu Voodoo
  • Saya tidak tahu apa itu Turbobloat. Dari konteksnya terbaca seperti “teknologi grafis yang tidak saya sukai”, tetapi tidak jelas batas mana yang termasuk Turbobloat
  • Membuat dan mengirim komputer baru mungkin saja bernilai dalam jangka panjang. Sebab peningkatan performa dan efisiensi daya seiring waktu dapat mengimbangi dampak lingkungannya
    Tentu kalau untuk hiburan, penilaiannya sulit; Game Boy lama bisa saja lebih menyenangkan daripada PC gaming modern 1000W

• Kalimat “Satu haruslah satu. Bukan beberapa hal yang berpura-pura menjadi satu. Jika memakai node, Anda harus membuat beberapa kumpulan berpura-pura menjadi satu” benar-benar terasa seperti Terry Pratchett dan sangat bagus
  Saya menyukainya karena terdengar seperti kalimat yang mungkin terlintas di benak Sam Vimes saat melakukan penyelidikan rumit, dan saya berharap ini terus berkembang. Saya belum mencobanya sendiri, tetapi ada ide yang bisa saya gunakan untuk proyek AI saya

  • Kalau kalimat itu dilihat terpisah, bukankah justru jelas-jelas keliru? Kita selalu memandang kumpulan dari banyak hal sebagai satu
    Manusia adalah kumpulan bagian tubuh, bagian tubuh adalah kumpulan bahan kimia, bahan kimia adalah kumpulan molekul, molekul adalah kumpulan atom, tetapi di tiap tingkat kita tetap melihatnya sebagai satu. Tidak masuk akal melarang hal itu. Meski begitu, proyeknya terlihat keren
  • Rasanya Sam Vimes akan mengatakan hal seperti itu, lalu mengalami perkembangan menyakitkan karena Sybil dan dengan enggan mengakui bahwa “kadang-kadang satu mungkin memang harus lebih dari sekadar satu”
    Dan entity component system milik Vetinari, meski tampak rumit, bekerja dengan benar dan membuat kota sialan itu tetap berjalan
  • Frasa ini tampaknya ditujukan untuk orang yang sudah mencoba solusi lain lalu tidak menyukainya, tetapi dari sudut pandang seseorang yang belum pernah memakai game engine, akan bagus jika dijelaskan secara sederhana bagaimana node terhubung dengan “kumpulan beberapa hal yang berpura-pura menjadi satu”
    Mungkin maksudnya pengalaman pengguna editor node mendorong kita memberi properti dan relasi pada sesuatu seperti Vector dari Finger, tetapi pada akhirnya Vector hanyalah “kumpulan benda”, bukan “jenis” yang memiliki perilaku sendiri, sehingga sulit menempelkan kode padanya.
    Saya penasaran apakah “semuanya adalah Entity dan tulis saja kode” berarti lebih mengarah pada membuat kelas Hand yang menampung Fingers serta memiliki state dan perilakunya sendiri, ketimbang Vector. Atau mungkin maksudnya, alih-alih membuat instance node yang sudah mengikat nilai statis dan anggota relasi tertentu, kita sebaiknya mewarisi lagi subclass Entity agar lebih spesifik
  • Paragraf berikutnya menarik: “Saat membuat sesuatu dengan node, Anda harus terus bolak-balik antara GUI node dan kode”
    Susunan Node/GDScript Godot dapat dilihat sebagai semacam respons terhadap klaim ini. Dengan operator $ dan autocomplete, Godot mencoba membuat “bolak-balik” itu semulus dan seterintegrasi mungkin. Meski begitu, pada akhirnya game harus dirilis, jadi menurut saya cara berpikir “satu adalah satu” pada akhirnya menang
  • Sayangnya, segala sesuatu adalah kumpulan hal-hal yang berpura-pura menjadi satu, bahkan hal yang tunggal sekalipun. Hal terbaik yang bisa kita lakukan hanyalah berpura-pura begitu, atau menghindarinya agar tidak ketahuan

• Seiring waktu, saya merasa ada semacam kekuatan eksternal yang menurunkan kualitas game engine. Hal-hal yang menyebar luas di dunia teknologi umumnya adalah hal-hal yang mudah dijadikan kurikulum
  Editor berbasis node seperti Unity strukturnya pas untuk dijelaskan dalam beberapa sesi kuliah. Sebaliknya, engine seperti raylib bisa dipahami dalam setengah hari, sehingga sulit membentuk kelas raylib tingkat universitas. Akibatnya muncul siklus: sekolah bergaya bootcamp meluluskan developer amatir yang hanya tahu Unity/Unreal, perusahaan merekrut tenaga Unity/Unreal, lalu universitas kembali mengajarkannya. Ini mirip dengan fenomena populernya Java.
  Selain itu, karena tiap perusahaan punya kebutuhan proyek Unity yang berbeda, Unity harus terus menyesuaikan engine-nya sebagai perusahaan komersial yang berhadapan dengan pelanggan, bukan sebagai satu programmer penuh keluhan, dan akhirnya menjadi Turbobloat. Engine Half-Life dan Morrowind lahir dari situasi unik ketika para programmer yang bersemangat dibayar untuk mengembangkan hal-hal yang menurut mereka keren, sehingga menghasilkan engine minimal yang sesuai bagi developer game profesional dan teknologi yang hebat.
  Proyek ini tampaknya berada di antara raylib dan Unity. Saya khawatir ia kurang menarik bagi programmer amatir, dan mungkin melakukan terlalu banyak hal bagi programmer yang menginginkan engine kecil. Semoga saya keliru, dan performa serta tingkat penyelesaiannya terlihat bagus. Jelas ada developer yang lelah dengan Unity, dan seiring siklus nostalgia bergeser ke era 2000-an, memang ada permintaan nyata untuk memainkan dan membuat game yang secara grafis tidak serumit Half-Life 2. Desain web dan nada dokumentasinya juga bagus

  • Penting juga bahwa ketika game dan engine dibuat bersama-sama, keduanya bisa saling menyesuaikan. Di Doom, kita tidak bisa menaruh lantai lain di atas lantai, yang merupakan batasan engine akibat keterbatasan CPU, dan para desainer level membuat trik agar tampak seperti itu
    Jika keduanya dirancang bersama, fitur yang ditambahkan bisa dimanfaatkan secara aktif, sementara fitur yang kurang bagus bisa dihindari, atau bahkan gaya seni bisa disesuaikan dengan engine. Mob Minecraft yang berpiksel dan bersudut cocok dengan engine-nya, tetapi jika mulai dibuat lebih detail, sebelum dirender dengan baik menggunakan poligon yang cukup, hasilnya justru jatuh ke uncanny valley yang terlihat lebih tua dan canggung daripada Minecraft
  • Saya ingat seseorang yang pernah bekerja di Bioshock, mungkin lead designer, berkata dalam sebuah wawancara: “Kalau ingin bereksperimen dengan ide baru di perusahaan, harus membentuk tim dan menghabiskan setidaknya sebulan sebelum ada sesuatu yang bisa disentuh. Sementara di rumah, dalam satu malam saya bisa membuat satu kampanye Doom penuh”
  • Saya suka pengembangan game berbasis library seperti raylib atau libgdx, tetapi ada alasan mengapa game seperti Slay the Spire pada sekuelnya beralih dari Unity ke Godot
    Saya rasa orang tidak memakai Unity karena salah diajari oleh profesor yang menyukai kompleksitas
  • Game lama benar-benar tajam, sementara game sekarang berjalan berantakan, crash, butuh unduhan 150GB, dan butuh 150 tahun untuk dijalankan. Kalau kita bermain game demi grafis, salah satu MMO paling populer tidak mungkin berbasis game browser tahun 2002, dan sejak awal kita pasti bermain realitas, bukan game
    Lihat saja apa yang dilakukan Epic Games pada Fortnite. Mereka membunuh game yang berfokus pada skena kompetitif dan tadinya berjalan mulus itu demi grafis Turbobloat dan skin
  • Fenomena “muncul programmer yang hanya tahu Unity/Unreal, perusahaan merekrut tenaga Unity/Unreal, lalu universitas kembali mengajarkannya” juga terlihat serupa di ArcGIS

• Saya sepenuhnya setuju dengan masalah pembengkakan turbo. Mesin sekarang jauh lebih kuat, tetapi sebagian besar program justru terasa lebih lambat daripada dulu
  Proyeknya juga sangat keren dan desain situs webnya A+

  • Klaim bahwa “sebagian besar program lebih lambat daripada dulu” rasanya hanya benar bagi orang-orang yang beruntung pernah memakai hardware yang sedikit terlalu bertenaga pada periode tertentu
    Dari sudut pandang orang yang memakai hardware biasa pada era Windows 98/2000/XP, menjalankan Windows 10/11/KDE/Gnome dan sebagainya di laptop modern murah dengan SSD terasa jauh lebih responsif, bahkan saat menjalankan webapp yang dianggap bloat seperti vscode atau Slack
  • Saya tidak paham istilah Turbobloat. Saya pernah membuat game tetapi belum pernah mendengarnya, penulis juga tidak mendefinisikannya, dan jika dicari di Kagi yang muncul hanya postingan ini, sementara di Google tidak ada hasil terkait
    Saya penasaran apakah artinya sekadar “sangat bloat”. Setelah membaca situsnya lebih lanjut, ada juga ungkapan seperti “simulasi fisika super-realistis”, jadi sepertinya pada akhirnya memang berarti “sangat bloat”

• Pandangan bahwa “sebagian besar game Unity terlihat sangat buruk meski memakai shader mencolok, normal mapping, dan teknik lain” tampaknya makin umum di kalangan generasi tertentu
  Yang jelas, ada semacam teknologi texture mapping yang telah menghilang. Latar Ikaruga bagus melebihi kebutuhan, terutama efek hutan sederhana di bagian awal. Beberapa simulator kereta era PS2 juga berhasil melakukannya.
  Namun cara ini runtuh ketika sumber cahaya berarah yang kuat seperti matahari menerangi benda mengilap dan pemain bergerak. Jika lingkungannya mendung dan sama sekali tidak ada objek dinamis, banyak trik modern bisa cukup banyak dihindari

  • Benar. Masalahnya, beberapa game modern tetap memakai Lumen padahal suasananya mendung dan tidak ada pencahayaan dinamis. Remake Silent Hill begitu; berjalan sangat lambat, terlihat lebih buruk di PS5 Pro, dan rumputnya pun tampak kalah dari game lama
    Latar Silent Hill aslinya dibuat untuk membenarkan trik optimisasi. Mereka menempatkan ruang berkabut permanen, “ruang kabut”, agar pengelolaan objek di layar lebih mudah, tetapi remake-nya menghamburkan pemrosesan besar-besaran untuk membuat kabut realistis alih-alih kabut yang tampak supernatural
  • Game-game bagus yang dibuat dengan Unity tidak terlihat “seperti game Unity”, jadi orang tidak mengingatnya sebagai contoh “seperti apa game Unity terlihat”. Karena itu, stereotip game Unity tetap saja “cukup kasar”
    Keterampilan seni untuk membuatnya terlihat bagus sama sekali belum hilang; hanya saja distribusinya sangat tidak merata. Tim dengan modeler, texture artist, animator, dan kemampuan visual programming yang bagus akan bisa membuat sesuatu tampak hebat, baik dengan Unreal, Unity, maupun engine sendiri
  • Ada keyakinan keras bahwa material saja bisa mengatasi texturing dan normal mapping yang kurang. Itu tidak benar, dan merupakan hasil dari salah paham atau distorsi atas materi pemasaran dari sesuatu seperti Unreal Engine
    Di Super Mario Sunshine, bayangan “tajam” yang tidak bisa dirender GameCube sebenarnya memakai mesh datar. Di Delfino Plaza, bayangan di bawah kanopi dekat Shine Gate bukan tekstur, melainkan mesh. Sebaliknya, alasan alun-alun ubin tempat bayangan mesh itu berada tampak bagus bukan karena satu tekstur raksasa, melainkan karena puluhan tekstur 128x128px di-UV mapping dengan benar.
    Kalau itu game modern, mungkin akan memakai dua tekstur bata dan pola noise untuk mencampurnya, ketiganya berukuran 2048x2048px, lalu bayangannya dibuat bertepi tajam dengan ray tracing. Ironisnya, meski VRAM dan kecepatan bus meningkat, kita memilih tekstur yang lebih besar alih-alih tekstur yang lebih banyak. Normal mapping juga serupa: alih-alih memakainya bersama model yang lebih tersubdivisi, orang keliru mengira normal map itu kuno dan bahwa memodelkan semua detail secara nyata adalah jalan yang lebih maju secara teknis. Bola yang tidak terlalu bersudut itu baik, tetapi memodelkan secara nyata setiap retakan dan goresan pada bola adalah bodoh dan boros komputasi
  • Dengan sesuatu seperti Unity, kita bisa membuat sesuatu yang berfungsi cukup cepat, tetapi agar benar-benar terlihat keren dibutuhkan keterampilan dan pemolesan tersendiri
    Bahkan game “2D” seperti Factorio pun punya perbedaan polishing yang sangat besar antara rilis pertama, versi 1.0, dan versi saat ini. Perbedaan ini juga jelas pada game yang memakai mod; aset mod biasanya “bisa dipakai”, tetapi tidak tampak sehalus konten utama

• Baru-baru ini saya memainkan lagi Half-Life 2, dan terkejut melihat betapa bagusnya game itu bahkan sekarang tanpa paket tekstur resolusi tinggi

  • Menurut saya ini karena art style game tersebut dipilih dengan sangat cerdas. Ada banyak permukaan difus yang cocok dengan pencahayaan yang sudah di-bake sebelumnya, dan langit mendung memungkinkan ambient light yang menyebar, bukan pencahayaan berarah yang memaksa shading bergantung sudut serta kontur bayangan tajam berkontras tinggi
    Permukaan mengilapnya pun kebanyakan tidak terlalu glossy, dan itu membantu. Pilihan-pilihan seperti ini terasa masuk akal dan cocok dengan dunia distopia ekstrem yang tua dan diduduki, sementara tekstur dengan warna kalem menyatukan semuanya
  • Karena itu saya pikir art direction yang benar-benar bagus selalu mengalahkan performa grafis murni. Source memang sudah impresif pada masanya, tetapi bagian yang bertahan lama adalah seberapa cermat lingkungan dan modelnya dirancang
    Valve memusatkan sumber daya untuk memasukkan detail dan memaksimalkannya dalam batasan teknis, dan bahkan 20 tahun kemudian hasilnya tetap terlihat kohesif dan dirancang dengan baik
  • Half-Life 2 telah menerima beberapa pembaruan pada shading dan tingkat detail sejak dirilis, jadi terlihat sedikit lebih baik daripada saat peluncuran. Meski begitu, pada saat rilis pun game ini sudah mengesankan secara visual
  • Belum sampai seminggu lalu saya memainkan lagi Half-Life 2, dan saya jadi berpikir bahwa “meski levelnya tidak sepenuh detail seperti game modern, arah artistik grafis dan desain levelnya lebih baik daripada banyak desainer modern dengan anggaran lebih besar”
  • Black Mesa, remake HL1 dengan engine HL2, juga layak dimainkan. Saya mencobanya saat pandemi dan tidak menyesal

• Dari sudut pandang saya yang bekerja di tim kecil pembuat game low-poly dengan Godot, ini keren
  Pernyataan seperti “saat membuat sesuatu dengan node, kita harus terus bolak-balik antara GUI node dan kode” serta “engine arus utama punya satu editor game raksasa, dan apa pun fitur yang dipakai, kita harus menunggu 10 menit sampai semuanya dimuat” sangat terasa. Bahkan di Godot, saya hampir tidak memakai fitur-fitur mewah, tetapi debug loop terasa jauh lebih lambat dibanding saat saya memrogram di lingkungan lain.
  Saya juga suka gagasan beberapa editor bekerja bersama di sekitar satu spesifikasi file data. IDE terpadu memudahkan beberapa developer menciptakan merge conflict, jadi editor dengan tujuan lebih spesifik juga bisa membantu developer per peran membatasi cakupan dan sifat perubahan. Saya menantikan bagaimana engine ini berkembang

  • Bulan lalu di hackathon, saya cukup bangga karena berhasil mencari cara melakukan test-driven development untuk modul C# tanpa membuka Unity
    Saya tetap bisa menyumbang bagian saya bahkan dengan netbook berperforma rendah. Saya belum pernah menulis satu baris pun C#, tetapi saya tidak berniat menyerah pada TDD dari command line. Saya tahu itu mungkin, dan akhirnya berhasil membuatnya jalan. Semua orang mengira saya gila, dan para developer relations dari sponsor juga sama sekali tidak membantu.
    Friksi terbesar akhir pekan itu tetap saja komputer terbaik harus menghabiskan waktu terasa seperti keabadian untuk menyalakan dan menyalakan ulang IDE Unity sialan itu. Mengejutkan betapa besar belenggu yang ditoleransi orang

• Mereka memakai istilah “Turbobloat” dan mengatakan engine ini “bloat”, dan sampai batas tertentu itu benar. Namun ada baiknya menjelaskan apa arti itu bagi mereka, fitur apa yang dianggap bloat, dan apa yang dihapus dari proyek Tramway
  Misalnya, bagi sebagian orang, menyertakan framework RPG pun bisa terlihat sebagai bloat, sementara Tramway memilikinya

  • Karena itu, fitur tersebut dimasukkan sebagai ekstensi opsional. Memang bagian dari proyek engine yang lebih besar, tetapi sepenuhnya opsional
    Saya suka prinsip C++ bahwa “Anda hanya membayar untuk apa yang Anda gunakan”

• Tertulis “cara menggunakan framework untuk pemula yang takut pada C++ atau memang tidak bisa C++”; saya termasuk yang kedua, dan saya berterima kasih pada halaman Getting Started.
  Teko teh muncul, dan saya memahami hal-hal yang tadinya saya kira tidak akan saya pahami. Sekarang saya hanya punya 30 menit saat makan siang sehingga tidak sempat menyelesaikan tutorial, tetapi fakta bahwa saya jadi ingin melanjutkannya menunjukkan betapa menyenangkan dan mudah didekatinya dokumentasi ini.

• Ada yang menemukan halaman Design Patterns? Itu semacam papan skor dengan target 100%, dan saya sangat menyukainya.

  • Ditautkan dari halaman beranda: “Design pattern yang digunakan: 82%. Kalau semua pattern sudah dipakai, proyek ini akan dihapus dan ditulis ulang dengan Rust. Tanpa pemrograman berorientasi objek.”
  • Sudah lama mencarinya, tapi masih belum menemukannya.