Core, teknologi baru eksperimental untuk membuat video game

 (github.com/damn)
2 poin oleh GN⁺ 2024-09-09 | 1 komentar | Bagikan ke WhatsApp

  • Apa itu coreCore

    • coreCore adalah cara eksperimental untuk membuat video game dalam bentuk alat dan engine pembuatan game Action-RPG serta editor properti
    • Menggunakan sistem komponen sederhana, dan komponennya berupa vektor clojure dengan bentuk [keyword value]
    • Berbagai entitas disusun sebagai map clojure
    • Efek samping di dalam game ditangani sebagai komponen seperti [:tx/foo param], yang mirip dengan struktur datomic
    • Seluruh status game disimpan dalam satu atom bernama app/state, dan entitas juga ada sebagai atom di dalam atom utama
    • Seluruh isi aplikasi disimpan di resources/properties.edn, divalidasi menggunakan malli-schemas, dan dapat diedit melalui GUI

  • Tangkapan layar

  • Cara memulai pengembangan

    • Masukkan perintah berikut:
      • lein dev
    • Aplikasi akan dimulai dan juga melakukan hal-hal berikut:
      • Menjalankan server NREPL
      • Saat aplikasi ditutup (ESC di menu utama), clojure.tools.namespace akan memuat ulang file yang berubah dan memulai ulang aplikasi
      • Jika terjadi error, tidak perlu me-restart JVM; cukup perbaiki error lalu panggil dev-loop/restart!
      • Di VIM, Anda dapat mengikat perintah berikut ke tombol F5: nmap <F5> :Eval (do (in-ns 'dev-loop)(restart!))

  • Lisensi kode

    • Disediakan di bawah lisensi MIT

  • Lisensi aset

Ringkasan GN⁺

  • coreCore adalah alat untuk memudahkan pembuatan game Action-RPG dengan menggunakan sistem komponen sederhana untuk mengelola status game
  • Seluruh status game disimpan dalam satu atom, dan properti dapat diedit melalui GUI sehingga berguna bagi developer
  • Disediakan dengan lisensi MIT, tetapi aset yang digunakan bersifat proprietari
  • Alat dengan fungsi serupa antara lain RPG Maker dan Unity

Bacaan terkait

1 komentar

 
GN⁺ 2024-09-09
Komentar Hacker News

  • Keren. Saya belum pernah merilis game, tetapi selalu suka melihat pendekatan yang berbeda terhadap pengembangan game
    Sejauh ini Bevy terasa bagus di awal, tetapi bisa punya banyak masalah implementasi dan menjadi berantakan, sedangkan Unity, dengan gameobject dan pendekatan komponen komposisionalnya, terasa paling praktis: engine tidak menghalangi dan lebih mudah menghindari spaghetti
    Saya tidak suka Godot. Hierarki object-oriented yang buruk, bahasa bawaan yang kurang bagus, dan “signals” yang dimaksudkan untuk mengurangi spaghetti justru malah menambahnya. Pygame cukup bagus untuk proyek kecil, dan di atas fondasi proseduralnya kita bisa menambahkan sendiri lapisan object-oriented atau fungsional
    Saya tidak tahu Clojure, tetapi menarik bahwa mereka mencoba implementasi fungsional di bidang yang biasanya tampak sangat cocok dengan object-oriented

    • Sebagai developer game profesional yang pernah membuat produk nyata dengan Unity maupun Godot, saya sama sekali sulit setuju dengan penilaian tentang Godot dan Unity itu
      signals di Godot adalah kemajuan besar dibanding kurangnya modularitas pada kelas bawaan Unity. Godot dan Unity pada dasarnya memiliki model scene/node/component yang sama, tetapi menurut saya Godot melakukannya lebih baik
      Keunggulan Unity adalah renderer 3D, PhysX bawaan, backend il2cpp untuk C#, profiler, performa runtime secara umum, dan dukungan konsol. Sebaliknya, desain Godot lebih kohesif, sementara Unity terasa terpecah ke 10 arah sejak sekitar 2018
    • Saya bukan developer game, tetapi desain object-oriented Godot termasuk yang cukup bagus di antara yang pernah saya pakai
      Sekarang saya lebih banyak di C++ embedded sehingga tidak banyak memakai object-oriented, tetapi saya belajar pemrograman dengan C#, jadi cukup terbiasa dengan inheritance
    • Godot itu luar biasa, dan saya rasa sekitar 5 tahun lagi akan menjadi Blender untuk pembuatan game. Versi 4 sudah layak dipakai di produksi dan mampu menangani sebagian besar proyek indie
      Area yang masih diungguli Unity adalah kelas “Triple I” dan “Double A”, karena fitur 3D/performa, tools, dan add-on-nya lebih baik. Untuk proyek AAA, keduanya bukan pilihan terbaik
      Untuk game 2D dan 3D sederhana, sekarang rasanya tidak ada alasan memakai Unity, dan saya kira Godot perlahan akan menyalip sementara pangsa Unity terus menurun
    • Sebagai developer komersial, dulu saya memakai Unity dan sekarang memakai Godot. Saya paham kritik terhadap GD Script dan signals, dan saya menghindarinya dengan event handling C#
      Yang paling membuat frustrasi adalah node dan hal-hal yang entah bug editor atau memang fitur, dan sangat terasa bahwa awalnya dibuat untuk proyek “kecil”
      Karena itu saya hampir tidak memakai editor selain untuk menyusun scene dan mengatur hierarki secara kasar. Tools sehari-hari saya adalah Emacs+C# LSP, debugging dengan VS Code, dan penyesuaian scene tree dengan editor Godot
    • Saya pernah memakai Godot cukup serius dan ada alasan untuk tidak menyukainya, tetapi menurut saya GDScript bukan salah satunya
      Pada dasarnya itu seperti Python yang ditambahi semantik slot/emit dan diintegrasikan dengan editor, jadi justru cukup bagus. Daripada memakai sistem build, metadata, dan file konfigurasi eksternal untuk integrasi yang rumit, lebih baik hal seperti itu ada di dalam bahasa

  • Katanya bisa membuat pengembangan game menjadi sederhana, tetapi malah melempar banyak jargon seperti Clojure vectors, datomics, atoms, transactions, dan malli schemas. Ada yang bisa menjelaskan?

    • Kalau teks pengantarnya dirapikan, Core adalah tool eksperimental yang mencoba menyederhanakan pembuatan action RPG
      Elemen dan properti game direpresentasikan sebagai struktur data sederhana, dan seluruh state game disimpan dalam satu container (app/state) agar mudah dikelola dan diperbarui
      Selain itu, Core menyediakan GUI untuk mengedit konten game yang disimpan dalam satu file (resources/properties.edn), sehingga lebih mudah diakses non-programmer, dan memakai skema Malli untuk validasi data, dengan tujuan menjaga konsistensi konten dan mengurangi error
    • Agar adil, mereka hanya bertanya apakah pengembangan game bisa dibuat lebih sederhana. Jawabannya kemungkinan besar “tidak”
    • Catatan wajib: “simple tidak sama dengan easy”: https://www.youtube.com/watch?v=SxdOUGdseq4
      Clojure vector pada dasarnya mirip list. Atom adalah referensi mutable yang menunjuk ke struktur data immutable, bisa dilihat seperti pointer dengan semantik pembaruan tertentu
      Transaction mirip transaksi database: mengubah beberapa struktur data sekaligus, tetapi baru commit jika semua operasi berhasil; jika gagal, rollback atau coba ulang
      Malli schema adalah cara melakukan type checking di bahasa bertipe dinamis, sedangkan Datomic adalah implementasi database non-SQL berbasis struktur data immutable; perubahan tidak menimpa secara destruktif, melainkan hanya menambahkan, sehingga bisa diputar balik ke titik waktu mana pun di masa lalu
    • Bahasa Clojure memiliki model manajemen state bawaan, dan proyek ini mencoba menerapkan model tersebut ke pengembangan game
      Menurut saya cara terbaik mempelajari model ini adalah menonton ceramah “Are we there yet” dari pencipta Clojure, Rich Hickey
    • Clojure vector adalah struktur data bawaan bahasa dan bentuknya seperti [1 2 3]
      Saya menggunakannya untuk menyusun efek samping seperti [:tx/foo 3], dan menyebutnya transaction, mirip Datomic. Di sini :tx/foo adalah keyword yang secara unik mengidentifikasi perilaku komponen

  • Jujur, menurut saya proyek ini sebenarnya gagal. Ini kekacauan yang terlalu direkayasa dan tidak punya struktur yang jelas
    Masalah terbesarnya adalah sama sekali tidak ada spesifikasi. Entah karena mereka tidak membuat cerita game, atau mungkin menganggap game tidak perlu cerita. Jadi mereka hanya bersenang-senang coding dengan Clojure dan coding gila-gilaan

    • Kalau adil, banyak juga proyek sukses yang merupakan kekacauan terlalu direkayasa dan tidak punya struktur jelas
      Bagus bahwa mereka mencoba sesuatu yang keren, dan ini area yang diminati banyak orang
    • Mengakui bahwa ini sekadar hobi yang menyenangkan, dan bahwa hasilnya mungkin tidak sesederhana yang diklaim, saja sudah menempatkan mereka di depan banyak orang. Semoga mereka belajar banyak dari proyek ini

  • Sebagai pengembang game, GitHub ini terasa konyol. Ini hampir seperti parodi dari keterlarutan akademis pada diri sendiri yang dibenci para pengembang game. Screenshot yang jelek itu jadi sentuhan pamungkasnya

    • Kalau begitu, bukankah ini kurang cocok dengan situs ini? Hacker News pada umumnya adalah tempat yang membahas ide-ide baru yang menarik, bukan hanya perbaikan bertahap pada C++ dan Unity
      Saya bisa memikirkan beberapa game yang lahir dari keterlarutan akademis aneh semacam ini. Jonathan Blow di komentar sesama thread juga begitu, dan begitu melihat proyek ini saya langsung teringat Braid
      Generasi prosedural dulu juga topik menara gading, dan semua kemajuan dalam grafis 3D pada awalnya bermula dari paper konferensi yang sama sekali tidak realistis. Banyak hal yang kini arus utama di game dulunya adalah ide akademis yang niche
    • Saya tidak merasa screenshot-nya “jelek”, tetapi saya setuju bahwa README-nya secara fungsional tidak berguna. Tidak ada dokumentasi, tidak ada contoh, dan tidak ada penjelasan mengapa harus memakainya
      Ia gagal pada tahap paling dasar untuk menyampaikan apa yang dilakukannya
    • Membuat sesuatu yang merangsang secara intelektual juga ada nilainya. Bahkan kalau kamu menghabiskan 100 jam membuat datomics Clojure dan hanya membuat 1 jam konten level, 1 jam tetap lebih besar daripada 0 jam
      Kalau karena bosan kamu malah tidak membuat apa pun, ini justru menguntungkan. Mirip dengan logika Jonathan Blow memakai Jai dalam pengembangan indie
    • Memang tertulis eksperimental

  • Mengejutkan bahwa repositori ini memicu cukup banyak percakapan meski dokumentasinya sesedikit ini. Dilihat dari kodenya, ini lebih terlihat seperti proyek daripada game engine
    property editor-nya menarik, tetapi tulisan ini tampaknya direkomendasikan lebih karena judulnya daripada isinya

  • Bagus. Senang melihat pengembang yang melakukan pengembangan game dengan Clojure seperti saya. Kadang memang membuat pekerjaan sendiri jadi lebih sulit :)
    Saat ini saya sedang mengembangkan shooter TPS multiplayer 3D dengan Clojure. Kalau tertarik, demonya ada di sini: https://prototype-game.pages.dev
    Saya juga akan segera mengunggah tulisan blog tentang perjalanan pengembangannya

    • Momen ketika beberapa orang masuk ke ruang virtual, langsung berlari-lari, dan memakai chat dalam game adalah salah satu pemandangan favorit saya di internet

  • Saya suka Clojure, tetapi bukankah bahasa fungsional yang memakai struktur data immutable agak pilihan yang aneh untuk pengembangan video game?

    • Sangat mungkin, dan ada trade-off yang menarik
      Ini tulisan-tulisan yang saya suka terkait pengembangan game fungsional:
      https://prog21.dadgum.com/228.html
      https://prog21.dadgum.com/23.html
      https://prog21.dadgum.com/24.html
      https://prog21.dadgum.com/25.html
      https://prog21.dadgum.com/26.html
    • Rasanya cukup alami. Karena Clojure berbasis JVM, proyek ini memakai libgdx secara internal, bisa dideploy ke semua platform, dan ekosistem library-nya juga besar
      Selebihnya, dengan Lisp kita bisa melakukan hampir apa saja. Berkat cara Clojure menangani struktur data immutable dan sistem protocol-nya yang bagus (https://www.freshcodeit.com/blog/clojure-protocols-and-the-e...), saya bisa dengan mudah membagi seluruh game menjadi komponen-komponen terpisah
    • Tim Sweeney juga tampaknya bertaruh ke arah seperti itu lewat Verse di UEFN. Verse lebih dekat ke upaya membuat Haskell lebih mudah didekati
    • Tidak seaneh itu. Game AA atau AAA berikutnya mungkin tidak akan memakainya, tetapi immutability sering terlihat juga di ranah yang sangat interaktif seperti reducer React atau Redux
      Clojure punya potensi performa yang lebih baik daripada Ruby atau Python, dan keduanya pernah benar-benar dipakai dalam game indie komersial
    • Pemrograman fungsional hampir belum pernah benar-benar dicoba dalam pengembangan game. Ada kurangnya irisan antara industri pengembangan game dan akademia
      Studio-studio tentu saja cenderung menghindari risiko dan memilih strategi yang sudah akrab, seperti object-oriented atau memakai ECS untuk kumpulan entitas berskala besar
      Secara pribadi, saya melihat pemrograman fungsional bisa cocok, tetapi terlebih dahulu perlu ditemukan arsitektur yang memecahkan masalah pengembangan game nyata. Harus dimulai dari eksperimen kecil, dan game jam sangat pas untuk itu

  • Sudah ada platform pembuatan game komersial bernama Core yang berjalan di atas Unreal Engine 4
    https://en.wikipedia.org/wiki/Core_(video_game)

  • Sepertinya namanya kurang tepat. Sudah dipakai di bidang ini: https://www.coregames.com/create

    • Saya juga langsung terpikir itu. Terutama karena yang itu membuat game di dalam game, jadi bisa juga dilihat sebagai cara “baru” untuk menulis game

  • Akan menarik kalau menganalisis data “waktu/kompleksitas yang dicurahkan ke game engine” dan “kompleksitas/tingkat ketertarikan game yang dihasilkan”
    Sebagai pengembang game, saya memperkirakan keuntungan dari game baru yang lahir dari sistem template/engine sederhana akan berupa kurva logaritmik dengan hasil yang makin menurun
    Dengan kata lain, semakin baik kamu membuat mesin pencetak kue, semakin sedikit variasi kuenya