Mengembangkan Video Game Tanpa Game Engine (2025)

 (noelberry.ca)
33 poin oleh GN⁺ 2025-05-21 | 5 komentar | Bagikan ke WhatsApp
  • Bahkan tanpa game engine komersial, pengembangan game tetap bisa dilakukan dengan cukup mudah dan menyenangkan
  • Sebagian besar fitur engine besar tidak diperlukan, dan menulis alat sendiri meningkatkan fleksibilitas serta efisiensi pengembangan
  • Dengan memanfaatkan C# modern dan library open source, lingkungan pengembangan yang memadai bisa disediakan terlepas dari ukuran tim
  • Dengan menggabungkan library seperti FMOD, SDL3, Dear ImGui dan tool buatan sendiri, pipeline dapat disusun sesuai kebutuhan
  • Dari sisi pengembangan lintas platform, pemeliharaan, dan portabilitas, framework ringan yang dibangun sendiri sangat menguntungkan

Kata pengantar: refleksi seorang pengembang game dengan pengalaman 20 tahun

  • Pada 2025 pun saya masih mengembangkan video game tanpa game engine komersial
  • Orang-orang di sekitar saya sering terkejut karena saya tidak memakai engine komersial
  • Fitur dasar dari engine besar seperti Unity atau Unreal kurang memuaskan dibanding mengimplementasikannya sendiri, dan pada akhirnya banyak bagian tetap harus dibuat ulang
  • Saat memakai engine komersial, kita rentan terkena dampak perubahan kebijakan bisnis atau masalah akibat pembaruan
  • Membuat alat kecil yang benar-benar cocok untuk tiap proyek jauh lebih efisien, dan dalam jangka panjang juga lebih mudah dirawat

Memilih bahasa pemrograman yang dibutuhkan untuk pengembangan game

  • Selama bertahun-tahun, C# digunakan sebagai bahasa utama
  • C# modern telah banyak meningkat dibanding masa lalu dalam hal performa, sintaks, dan pengalaman pengembangan
  • Ada fitur hot reload seperti dotnet watch, sehingga sangat nyaman untuk mengubah dan menguji kode secara real time
  • Bahkan non-developer pun mudah mendekatinya, sehingga pembagian peran dan efisiensi kolaborasi antaranggota tim meningkat
  • Fitur reflection bawaan memberi keunggulan saat membuat editor atau tool

Library lintas platform serta implementasi rendering dan input

  • Menggunakan SDL3 untuk mengimplementasikan semua fungsi dasar seperti window, rendering, controller, dan dukungan lintas platform
  • Dengan GPU abstraction milik SDL3, dukungan untuk berbagai lingkungan seperti DirectX, Vulkan, Metal menjadi lebih mudah
  • Layer C# buatan sendiri di atas SDL (misalnya Foster) digunakan sebagai utilitas bersama
  • FMOD dipakai sebagai tool audio komersial terakhir yang tersisa; selain itu pipeline dibangun berbasis open source
  • Sebelumnya juga pernah berpengalaman mengimplementasikan OpenGL/DirectX secara langsung, tetapi stabilitas SDL memberi keuntungan yang besar

Cara menangani aset

  • Jika memakai engine buatan sendiri, cukup memuat file yang benar-benar dibutuhkan oleh game
  • Untuk aset berskala kecil seperti pada game pixel art, semua file dimuat sekaligus saat inisialisasi
  • Pada proyek besar, hanya aset yang diperlukan yang dimuat saat diminta, lalu memori dibebaskan ketika berpindah adegan
  • Jika perlu konversi, cukup menulis skrip pemrosesan otomatis saat kompilasi

Level editor dan tool UI

  • Mudah menghubungkan data dengan level editor open source seperti LDtk, Tiled, Trenchbroom
  • Pada umumnya, editor kustom diimplementasikan sendiri untuk tiap proyek
  • Alih-alih menulis UI utama sendiri, GUI immediate-mode dari Dear ImGui dimanfaatkan secara aktif
  • Kombinasi reflection di C# dan ImGui memungkinkan visualisasi status game object secara real time
  • Jika diperlukan, tool eksternal yang sesuai tujuan dapat dicampur dengan tool internal

Lintas platform dan portabilitas ke konsol

  • Dulu pemilihan C++ sangat penting karena masalah porting ke konsol, tetapi kemunculan C# Native-AOT membantu menyelesaikannya
  • Framework open source seperti FNA juga sedang aktif memperluas dukungan konsol
  • Jika memanfaatkan layer abstraksi umum yang didukung SDL3, basis kode yang sama dapat dijalankan di sebagian besar sistem

Lingkungan pengembangan: ekosistem terbuka berpusat pada Linux

  • Platform pengembangan utama telah dipindahkan ke Linux, dan sangat cocok dengan toolchain open source
  • Masih ada keterkaitan dengan beberapa software komersial tertentu (misalnya vscode, github), tetapi makin luas ekosistem open source, makin besar pula dukungannya
  • Secara pribadi, lingkungan kerja yang sama juga disiapkan di berbagai platform berbasis Linux seperti Steam Deck

Tanya jawab tambahan dan contoh

  • Pertanyaan tentang penggunaan Godot: jika kebutuhan pengembangan berfokus pada engine open source, Godot direkomendasikan; selain itu lebih menyukai tool kustom
  • Pekerjaan 3D: engine besar memang punya keunggulan, tetapi untuk proyek kecil yang sangat spesifik, framework kustom sudah memadai
  • Kebutuhan teknologi berperforma tinggi: tergantung tingkat kebutuhan, memakai engine besar seperti Unreal juga tidak masalah
  • Perubahan engine di tingkat tim: cocok untuk pengembangan kecil/solo, dan bahkan studio menengah-besar juga makin banyak beralih ke engine kustom untuk menghindari risiko jangka panjang
  • Workflow aset: file Aseprite dapat otomatis dikonversi menjadi animasi dengan memanfaatkan tag dan timing bawaan

Kesimpulan

  • Membuat game tanpa game engine komersial adalah pilihan yang bergantung pada selera dan cara kerja
  • Yang penting adalah memprioritaskan kebutuhan dan kesenangan, lalu memilih metode yang paling cocok untuk diri sendiri

Bacaan terkait

5 komentar

 
assembler 2025-05-29

Ini kegiatan yang bagus.
Saya adalah pengembang game generasi pertama.
Sebelum Unreal muncul, tentu saja studio pengembang
wajib mengembangkan engine sendiri,
dan itulah daya saing mereka.
Pengembangan engine pada dasarnya sebagian besar diisi oleh pengembangan tool
yang berbasis pada core, kernel, rendering, dan berbagai input/output lainnya.
Saat itu saya menangani tool partikel, suara, layer, dan objek,
dan jika anggota tim yang berjumlah 7 orang dikumpulkan,
sepertinya kami dengan mudah melampaui sekitar 20 tool.

Sejak suatu hari Unreal muncul dan game-game model produksi massal
bermunculan, mereka tidak lagi berinvestasi dalam pengembangan engine.
Sepertinya saat itulah banyak orang keluar dan mendirikan perusahaan sendiri.
Ternyata itu sudah cerita 27 tahun yang lalu.

Saya pun sekarang sudah bertambah tua dan bekerja di bidang lain, bukan game.

Ini mengingatkan saya pada masa-masa penuh nostalgia ketika saya mengerjakan core
sesuai mode directx dan opengl bergantung pada kartu grafis.

Semangat...
 
chanapple 2025-05-21

Belakangan ini saya sudah lama mencari engine untuk membuat game strategi, sampai berpikir kalau begini lebih baik bikin sendiri saja. Melihat ada contoh orang yang benar-benar mempraktikkannya dan berhasil, rasanya jadi makin bersemangat.
 
GN⁺ 2025-05-21
Komentar Hacker News

  • Selama 5 tahun mengembangkan engine game 2D sendirian sambil mengerjakan pekerjaan berbayar terkait, saya ingin menjelaskan poin penting yang sering tidak disadari orang
    Engine itu bagian yang mudah
    Yang benar-benar penting adalah tooling di sekitar engine, konten, dan pipeline aset
    Mengimpor tekstur, audio, file model (gltf, fbx, animasi, dll.) dari berbagai sumber data dan format
    Fitur editing dasar di aplikasi editor seperti potong, salin, tempel, undo, redo, simpan, hapus
    Visualisasi dan fitur yang memungkinkan developer membuat dan memanipulasi data nyata di editor (entity, animasi, scene, audio graph, dukungan scripting, dll.)
    Pengemasan data dan prapemrosesan seperti baking geometri statis, kompilasi shader, resampling dan packing tekstur/audio, pembuatan asset pack konten game
    Setelah semua itu selesai, bagian runtime yang sebenarnya (yakni main loop game dan subsistem di bawahnya) hanyalah sebagian kecil dari keseluruhan sistem
    Itulah sebabnya di studio game, orang yang menangani engine jumlahnya sedikit, sementara mayoritas adalah programmer yang membuat tool
    engine detonator: https://github.com/ensisoft/detonator

    • Penting untuk fokus membuat engine yang cocok untuk game saya sendiri, bukan mengejar tujuan serbaguna
      UI, kompresi, dan semacamnya bisa diselesaikan dengan library dan framework
      Pilihan OP memakai library kecil seperti imGUI juga contoh yang bagus
      Karena bukan membuat engine untuk semua jenis game, jadi ada banyak hal yang pada praktiknya tidak perlu dikerjakan

    • Engine itu seperti runtime kecil yang ditempelkan pada pipeline aset
      Belakangan ini compiler shader bahkan makin penting dibanding 3D API
      Bagian yang menarik terkonsentrasi pada compiler shader, sementara 3D API pada dasarnya hanya berperan menjalankan shader dan mengirimkan data

    • Saat orang mengatakan engine, mereka sering kali memasukkan pipeline aset dan editor ke dalamnya juga
      Engine masa kini bukan sekadar main loop + fungsi 3D API
      Meski memakai engine seperti Unity, sangat sedikit developer yang hanya menulis kode rendering
      Tentu saja, memakai Unity/Unreal juga bukan berarti sama sekali tidak perlu memakai tool aset sendiri

    • Saya sangat setuju dengan ini setelah baru-baru ini merombak engine untuk sekuel
      Seperti yang saya tulis di postmortem, kebanyakan orang membayangkan “engine” sebagai kode yang masuk ke executable game, tetapi secara nyata saya rasa porsi yang lebih besar justru adalah kode yang tidak didistribusikan bersama game, seperti level editor, pipeline konten, debugging/profiling, dan workflow development
      Pengembangan tool lebih membosankan dan lebih mudah menguras tenaga dibanding pengembangan engine
      Karena alasan inilah banyak pengembangan game dengan engine kustom berhenti di tengah jalan
      Postmortem: https://ruoyusun.com/2025/04/18/game-sequel-lessons.html

    • Membuat editor dari nol adalah pekerjaan yang sangat besar
      Kalau memungkinkan, lebih baik memanfaatkan editor yang sudah ada
      Misalnya kombinasi TrenchBroom (editor Quake) + func_godot, dan untuk 2D ada Tiled
      Untuk pengelolaan data game dulu ada CastleDB, tetapi sekarang sudah terintegrasi dengan Hide (editor 3D yang lebih serius)
      Setelah tool selesai dibuat, mendesain game dan membuat kontennya juga menjadi tahap utama berikutnya

  • Beberapa tahun lalu saya membuat kelas sprite sederhana dengan SDL2 dan sedikit C++, lalu menambahkan fitur sederhana seperti collision
    Kalau apa yang saya buat itu mau disebut engine, mungkin lebih seperti bantuan sepeda listrik
    Poinnya adalah bahwa “engine” sering kali malah memimpin keseluruhan proyek/game
    Sering kali game akhirnya disesuaikan dengan engine, karena itu saya selalu menghindari engine besar seperti Unity
    Pada akhirnya engine-engine seperti itu hanya menghasilkan struktur game yang sama, yang berbeda cuma asetnya
    Secara pribadi, daripada membuang waktu mempelajari engine, saya lebih suka mulai dengan SDL yang kurva belajarnya pendek, dan SDL juga bisa dipakai untuk proyek lintas platform lain di luar game
    Game saya: https://store.steampowered.com/app/2318420/Glypha_Vintage/

  • Memang membuat engine sendiri butuh waktu lama, tetapi saya bertanya-tanya berapa banyak waktu yang dibutuhkan untuk benar-benar menguasai Unreal atau Unity sampai bisa langsung menuangkan ide menjadi game
    Begitu pembuatan engine saya selesai, pada akhirnya saya juga mendapatkan tingkat keahlian itu secara langsung, jadi dalam jangka panjang ini menghemat waktu
    Semakin panjang karier saya sebagai engineer, semakin terasa bahwa membuat sendiri lebih menguntungkan dari sisi waktu
    Semakin unik atau niche game-nya, semakin masuk akal membuat sendiri
    Menghabiskan beberapa bulan tersesat di UI Unreal yang rumit lalu sadar bahwa hal yang sebenarnya diinginkan hampir mustahil dilakukan di engine generik sejak awal itu tidak efisien
    Sebaliknya, kalau yang dibuat adalah RPG open world superambisius, membuat sendiri jelas bukan pilihan yang baik
    Keterbatasan engine kustom justru bisa memunculkan kreativitas, dan meski tidak mencapai level tertinggi, hasilnya bisa jadi game yang lebih orisinal

    • Saya pernah membuat engine sendiri
      Awalnya butuh sekitar 1 tahun sambil melewati banyak trial and error dan jalan buntu
      Saya mengimplementasikan hampir semua subsistem yang biasa ada di game: rendering 3D, UI adaptif, skeletal animation, save file, smart object, pathfinding, scripting, audio, fisika, dan lain-lain
      Secara khusus saya juga mengimplementasikan fitur rewind (seperti sistem di Braid) sendiri
      Fitur seperti ini membutuhkan dukungan dari semua subsistem engine (script, fisika, dll.)
      Karena saya memahami semua bagian engine yang saya buat, saya punya kebebasan luar biasa untuk mengembangkan fitur tambahan
      Tetapi setelah 1 tahun pengembangan, saya makin burnout dan kehilangan motivasi

    • Saya tidak tahu soal Unreal, tetapi Unity memungkinkan pengembangan lebih dari 10 kali lebih cepat dibanding menulis semuanya sendiri
      Fitur fisika bisa ditambahkan dalam 1 menit, sedangkan kalau pakai engine buatan sendiri, hanya untuk mengintegrasikan library eksternal saja bisa makan waktu satu atau dua hari
      Fitur visualisasi internal yang ditunjukkan Noel untuk Unreal juga sudah ada di Unity
      Editing seperti memanipulasi bounding box juga tersedia secara bawaan
      Kalau perilaku dasar engine kurang, itu bisa dengan mudah diperluas menggunakan ImGui atau engine CSS berbasis Yoga
      Ada banyak fitur seperti particle editor canggih, shader yang kompleksitasnya sudah disederhanakan, modular data streaming, dan sebagainya
      Secara teori saya juga ingin membuat semuanya sendiri, tetapi pada akhirnya waktu terbatas dan yang utama adalah menyelesaikan

    • Waktu yang dibutuhkan untuk mempelajari Unreal atau Unity sampai bisa langsung mewujudkan ide game, dan waktu yang dibutuhkan untuk membuat engine sendiri, adalah dua pertanyaan yang berbeda
      Kalau diberi sedikit gambaran ide saja, saya bisa membuat prototipe yang sudah bisa dimainkan dalam hitungan jam
      Di Unity, pada tahap awal cukup dengan pemrograman, dan di Unreal, hanya dengan blueprint saja pun hampir bisa sampai mendekati rilis game
      Lihat video prototipe game gaya Super Hexagon yang selesai dalam 10 menit: https://www.youtube.com/watch?app=desktop&v=p8MzsDBI5EI
      Elemen yang benar-benar khas milik Unity mungkin cuma prefab; selebihnya adalah konsep umum pengembangan game
      Dari sudut pandang developer Unreal, membuat prototipe serupa di Unity pun mungkin bisa dilakukan dalam kurang dari 1 jam

    • Asumsi “setelah engine selesai” itu sendiri mungkin tidak realistis
      Bahkan aksi sederhana seperti GameObject.Instantiate pun membutuhkan sumber daya yang sangat besar jika harus diimplementasikan sendiri di engine
      Pertimbangkan kompleksitas fisika 2D/3D, shader, dukungan platform, dan lain-lain
      Kalau tujuan Anda adalah engine, buatlah engine; kalau tujuan Anda adalah game, buatlah game itu sendiri

    • Kalau pengetahuan pengembangan game Anda sudah cukup untuk membuat game engine
      Belajar Unreal atau Unity sampai bisa membuat prototipe hanya butuh satu hari
      Butuh waktu lama untuk benar-benar mahir, tetapi waktu untuk menyelesaikan prototipe game yang diinginkan tidak bisa dibandingkan

  • Membuat game tanpa engine besar yang “melakukan semuanya” itu lebih mudah, lebih menyenangkan, dan kadang lebih efisien
    Namun, saat harus mendalami fitur engine tertentu (misalnya inverse kinematics atau animation blending di Unreal), saya jadi berpikir “syukurlah saya tidak perlu susah-susah membuat ini sendiri selama 2–3 minggu”
    Minimalisme atau mencegah pembengkakan juga penting, tetapi engine-engine ini populer karena mereka menanggung pekerjaan berat itu untuk kita

    • Dulu saya juga seperti ini
      Saat membuat game 3D pertama, saya mengimplementasikan semuanya: input, manajemen objek, culling, loading model, library matematika, grafis, normal map, SSAA, dan seterusnya, lalu tingkat penyelesaian game-nya justru 0%
      Meski begitu, untuk proyek 2D hobi saya masih tetap melakukan pengembangan tanpa dependensi hanya dengan browser canvas
      Pada praktiknya browser itulah yang berperan sebagai engine

    • Menanggapi pendapat “syukurlah tidak membuat sendiri”
      Kalau memikirkan karier jangka panjang sebagai developer indie, meski butuh beberapa minggu, pemahaman yang lebih dalam + kepemilikan 100% atas source code dan nilai guna ulang tetap lebih besar

    • Skripsi kelulusan saya bertema mem-porting particle engine berbasis NeXTSTEP/Objective-C ke Windows 95/Visual C++ (berbasis OpenGL, termasuk sampel marching cubes)
      Tema seperti itu sekarang di engine modern mungkin cuma sebagian dari fitur satu baris

    • Memakai engine membuat proyek berjalan jauh lebih cepat, dan Anda tidak perlu menghabiskan waktu untuk membangun infrastruktur
      Bagi kebanyakan orang, menemukan kembali roda bukanlah hal yang terlalu menyenangkan

    • Fitur seperti inverse kinematics atau animation blending
      Kalau itu inti dari game-nya, maka layak diimplementasikan; kalau tidak, itu cuma jebakan teknis yang tidak perlu

  • Saya membuat game dengan cara saya sendiri memakai Lua & Love2D
    Bagian paling menyenangkan justru terletak pada memberi batasan pada diri sendiri
    Kalau pengembangan sudah tidak menyenangkan, itu tanda ada yang salah, jadi perlu mencari cara yang lebih baik
    Game saya YOYOZO kecil, hanya 39KB, tetapi masuk daftar game terbaik Ars Technica 2023 bersama judul-judul besar
    https://news.ycombinator.com/item?id=38372936

    • Saya ingat game itu
      Beberapa tahun setelah membeli Playdate, saya baru mulai bermain-main dengan SDK-nya, sambil untuk pertama kalinya belajar Lua juga
      Saya memang berharap ada strong typing dan keamanan bahasa yang lebih baik, tetapi untuk konteks ini rasanya sudah cukup
      Sejauh ini saya baru membuat demo teknis kecil berupa teks yang berputar di ruang 3D palsu mengikuti crank
      https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a
      Saat mengerjakan proyek ini, saya sadar bahwa setelah lama berkarier di CRUD/web app, saya hampir melupakan semua trigonometri
      Keunggulan terbesar pengembangan Playdate adalah kanvasnya tetap, jadi begitu posisi piksel ditentukan, hasilnya akan sama persis di semua perangkat, dan itu terasa sangat membebaskan
      Dalam pengalaman pengembangan saya sebelumnya yang selalu membuat UI responsif, pengalaman ini terasa sangat baru

  • Setiap kali mencoba membuat sesuatu dengan game engine (Godot, Unity, Unreal, dll.), saya selalu akhirnya bergulat dengan engine-nya
    Pada akhirnya terasa seperti hanya menaruh aset di atas format game yang sudah ditentukan, sehingga sulit membuat game yang benar-benar saya inginkan
    Kalau dianalogikan ke web development, rasanya seperti produk jadi semacam WordPress
    Saat konfigurasi dasarnya tidak sesuai dengan niat awal, dibutuhkan banyak hack dan solusi memutar yang besar

  • Penulisnya (Noel) membuat game bernama Celeste, yang telah terjual lebih dari 3 juta kopi
    https://en.wikipedia.org/wiki/Celeste_(video_game)

  • Saya juga cukup setuju, dan sedang membuat framework game C# berbasis kode (penerus spiritual XNA/Monogame, memakai Sokol alih-alih SDL)
    https://zinc.graphics/
    Kekuatan C# modern: lintas platform, kompilasi NativeAOT, native hot reloading, reflection, dan sebagainya
    Saya juga secara pribadi menambahkan source generator
    Memang masih ada citra negatif dari masa lalu, tetapi perkembangan CoreCLR dan bahasa ini dalam 5 tahun terakhir benar-benar luar biasa
    Satu-satunya hal yang saya harapkan hanyalah Union Types, dan itu sudah diajukan, jadi saya berharap akan ditambahkan tahun depan
    https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md

    • Saya penasaran apakah ada materi referensi untuk mulai belajar C# demi proyek seperti ini
      Saya hanya pernah memakai C# di Win32 atau Unity, dan meski punya pengetahuan engine tingkat rendah dari C/C++, saya dulu mengira C# tidak mungkin dipakai lintas platform seperti di game console
      Sekarang saya sadar pemikiran saya itu keliru

  • Untuk software apa pun, saya lebih suka memulai dari nol
    Bagi orang yang pernah menangani proyek besar, ini mungkin terasa lambat, tetapi pada tahap startup justru sering lebih cepat
    Cukup implementasikan yang minimum, lalu begitu abstraksi mulai terbentuk, kecepatan menambahkan fitur baru meningkat
    Produktivitas software enterprise besar dan mini engine yang saya tulis sendiri benar-benar berbeda
    Kode yang saya tulis sendiri jauh lebih cepat untuk dipotong dan direfaktor
    Karena itu saya menyukai microservice dan tim kecil
    Saat membuat sendiri, Anda pasti harus melewati trial and error dan ladang ranjau yang gampang rusak, dan juga butuh waktu bertahun-tahun untuk benar-benar memahami sifat asli bahasa atau platform
    Tetapi proses itu sendiri pada akhirnya menjadi fondasi kemampuan developer
 
kissdesty 2025-06-10

Bukan engine, saya penasaran bagaimana kalau memakai framework setingkat MonoGame~
 
lazyhack 2025-05-23

“Proses itu sendiri pada akhirnya akan menjadi jam terbang pengembang” — saya sangat setuju.