Video oyunları oluşturmak için deneysel yeni teknoloji: Core

 (github.com/damn)
2 puan yazan GN⁺ 2024-09-09 | 1 yorum | WhatsApp'ta paylaş

  • coreCore nedir

    • coreCore, Action-RPG oyun yapım aracı ve motoru ile özellik düzenleyicisi biçiminde video oyunları oluşturmak için deneysel bir yöntemdir
    • Basit bir bileşen sistemi kullanır ve bileşenler [keyword value] biçimindeki clojure vektörleridir
    • Çeşitli varlıklar clojure map'lerinden oluşur
    • Oyun içi yan etkiler [:tx/foo param] gibi bileşenlerle işlenir; bu, datomic yapısına benzer
    • Tüm oyun durumu app/state adlı tek bir atom içinde saklanır ve varlıklar da ana atomun içindeki atomlar olarak bulunur
    • Uygulamanın tüm içeriği resources/properties.edn içinde saklanır, malli-schemas kullanılarak doğrulanır ve GUI ile düzenlenebilir

  • Ekran görüntüleri

  • Geliştirmeye nasıl başlanır

    • Aşağıdaki komutu girin:
      • lein dev
    • Uygulama başlatılır ve aşağıdaki işlemler de yapılır:
      • NREPL sunucusu başlatılır
      • Uygulama kapanırken (ana menüde ESC), clojure.tools.namespace değişen dosyaları yeniler ve uygulamayı yeniden başlatır
      • Hata oluştuğunda JVM'i yeniden başlatmaya gerek kalmadan hatayı düzeltip dev-loop/restart! çağrılabilir
      • VIM'de F5 tuşuna şu komut bağlanarak kullanılabilir: nmap <F5> :Eval (do (in-ns 'dev-loop)(restart!))

  • Kod lisansı

    • MIT lisansı altında sunulmaktadır

  • Varlık lisansı

GN⁺ özeti

  • coreCore, Action-RPG oyunlarını kolayca üretmeye yönelik, oyun durumunu basit bir bileşen sistemiyle yöneten bir araçtır
  • Tüm oyun durumunu tek bir atomda saklaması ve özelliklerin GUI üzerinden düzenlenebilmesi, geliştiriciler için kullanışlıdır
  • MIT lisansıyla sunulsa da kullanılan varlıklar mülkiyetlidir
  • Benzer işlevlere sahip araçlar arasında RPG Maker ve Unity bulunur

İlgili okumalar

1 yorum

 
GN⁺ 2024-09-09
Hacker News yorumları

  • Harika. Hiç oyun yayımlamış olmasam da oyun geliştirmeye yönelik farklı yaklaşımları görmeyi her zaman seviyorum.
    Şimdiye kadar Bevy başta iyi görünüyordu ama uygulamada çok sorunu vardı ve dağınıklaşabiliyordu; Unity’de ise gameobject ve bileşimsel component yaklaşımı en pratik olanıydı, motor araya girmiyor ve spagettiden kaçınmak kolay oluyordu.
    Godot’tan hoşlanmadım. Kötü nesne yönelimli hiyerarşi, pek iyi olmayan yerleşik dil; spagettiyi azaltması beklenen “signals” ise aksine artırdı. Pygame küçük projeler için oldukça iyi; prosedürel bir temel üzerine nesne yönelimli ya da fonksiyonel katmanları kendiniz koyabiliyorsunuz.
    Clojure’u bilmiyorum ama tipik olarak nesne yönelimliliğe çok uygun görünen bir alanda fonksiyonel bir uygulama denemesi ilginç.

    • Unity ve Godot ile gerçek ürünler çıkarmış profesyonel bir oyun geliştiricisi olarak, Godot ve Unity hakkındaki değerlendirmeye hiç katılmak zor.
      Godot’un signals sistemi, Unity’nin yerleşik sınıflarındaki modülerlik eksikliğine kıyasla büyük bir ilerleme. Godot ve Unity temelde aynı scene/node/component modeline sahip, ama bence Godot bunu daha iyi yapıyor.
      Unity’nin güçlü yanları 3D renderer’ı, yerleşik PhysX’i, C# için il2cpp backend’i, profiler’ı, genel çalışma zamanı performansı ve konsol desteği. Buna karşılık Godot’un tasarımı daha bütünlüklü; Unity ise 2018 civarından beri 10 farklı yöne bölünmüş gibi hissettiriyor.
    • Oyun geliştiricisi değilim ama Godot’un nesne yönelimli tasarımı kullandıklarım arasında oldukça iyi olanlardandı.
      Şimdilerde C++ embedded tarafındayım, bu yüzden nesne yönelimliliği çok kullanmıyorum; ama programlamayı C# ile öğrendiğim için kalıtıma alışığım.
    • Godot harika ve yaklaşık 5 yıl sonra oyun yapımının Blender’ı olacağını düşünüyorum. 4. sürüm pratikte kullanılabilir durumda ve çoğu indie projenin altından kalkabilir.
      Unity’nin önde olduğu alan “Triple I” ve “Double A” seviyesi; çünkü 3D/performans özellikleri, araçları ve eklentileri daha iyi. AAA projeler içinse ikisi de en iyi seçenek değil.
      2D ve basit 3D oyunlarda artık Unity kullanmak için bir neden görünmüyor; Godot’un yavaş yavaş öne geçeceğini ve Unity’nin payının düzenli olarak azalacağını düşünüyorum.
    • Ticari geliştirici olarak eskiden Unity kullanıyordum, şimdi Godot kullanıyorum. GD Script ve signals eleştirilerine katılıyorum; ben bunu C# event handling ile aşıyorum.
      En sinir bozucu olanlar, node’lar ve editörde bug mı özellik mi belli olmayan şeyler; ayrıca başlangıçta “küçük” projeler için yapılmış hissi çok güçlü.
      Bu yüzden editörü scene oluşturma ve kabaca hiyerarşi ayarlama dışında neredeyse hiç kullanmıyorum. Günlük araçlarım Emacs+C# LSP, debugging için VS Code, scene tree ayarlamaları için Godot editörü.
    • Godot’u epey ciddi şekilde kullandım ve sevmemek için nedenlerim de var, ama GDScript’in bunlardan biri olduğunu düşünmüyorum.
      Temelde Python’a slot/emit semantiği eklenip editörle entegre edilmiş hali; bu yüzden aslında fena değil. Build sistemi, metadata ve harici ayar dosyalarıyla entegrasyon kuran karmaşık yaklaşımlardansa bunun dilin içinde olması daha iyi.

  • Oyun geliştirmeyi basitleştirebileceğini söyleyip Clojure vectors, datomics, atoms, transactions, malli schemas gibi bir sürü uzman terimi ortaya atıyor. Biri açıklayabilir mi?

    • Tanıtım metnini toparlarsak, Core aksiyon RPG yapımını basitleştirmeye çalışan deneysel bir araç.
      Oyun öğelerini ve özelliklerini basit veri yapılarıyla ifade ediyor; tüm oyun durumunu tek bir container’da (app/state) saklayarak yönetimi ve güncellemeyi kolaylaştırıyor.
      Ayrıca tek bir dosyada (resources/properties.edn) saklanan oyun içeriğini düzenlemek için bir GUI sunarak programcı olmayanlar için de erişilebilir kılmayı hedefliyor; Malli schema ile veri doğrulaması yaparak içerik tutarlılığı ve daha az hata amaçlıyor.
    • Adil olmak gerekirse, sadece oyun geliştirmenin basitleşip basitleşemeyeceğini soruyor. Cevap muhtemelen “hayır” olacaktır.
    • Zorunlu olarak gelen “basitlik kolaylıkla aynı şey değildir”: https://www.youtube.com/watch?v=SxdOUGdseq4
      Clojure vector temelde listeye yakın bir şeydir. Atom, değişmez bir veri yapısına işaret eden değiştirilebilir bir referanstır; belirli güncelleme semantiği olan bir pointer gibi düşünülebilir.
      Transaction, veritabanı transaction’ına benzer şekilde birden fazla veri yapısını aynı anda değiştirir; tüm işlemler başarılı olursa commit eder, başarısız olursa rollback yapar ya da yeniden dener.
      Malli schema, dinamik tipli bir dilde tip kontrolü yapma yöntemidir; Datomic ise değişmez veri yapılarına dayanan SQL dışı bir veritabanı uygulamasıdır. Değişiklikleri yıkıcı biçimde üzerine yazmak yerine yalnızca ekleme yapar, böylece geçmişteki herhangi bir ana geri sarıp bakmayı mümkün kılar.
    • Clojure dilinde yerleşik bir state management modeli var ve bu proje o modeli oyun geliştirmeye uygulama girişimi.
      Bu modeli öğrenmenin en iyi yolunun Clojure’un yaratıcısı Rich Hickey’nin “Are we there yet” konuşmasını izlemek olduğunu düşünüyorum.
    • Clojure vector, dilin yerleşik veri yapısıdır ve [1 2 3] gibi görünür.
      Ben bunu [:tx/foo 3] gibi yan etkileri oluşturmak için kullanıyorum ve Datomic’e benzer şekilde buna transaction diyorum. Burada :tx/foo bir keyword’dür ve component davranışını benzersiz şekilde tanımlar.

  • Açıkçası bu projenin pratikte başarısız olduğunu düşünüyorum. Aşırı tasarlanmış bir karmaşa ve net bir yapısı yok.
    En büyük sorun, hiç spesifikasyon olmaması. Oyun hikâyesi yapmadı ya da belki de oyunların hikâyeye ihtiyacı olmadığını düşündü. Bu yüzden sadece Clojure ile kod yazmak eğlenceli geldiği için çılgınca kod yazdı.

    • Adil bakarsak, başarılı projeler arasında da aşırı tasarlanmış karmaşa olan ve net yapısı olmayan çok şey var.
      Havalı bir şey denemiş olması iyi; birçok insanın ilgilendiği bir alan.
    • Bunun sadece eğlenceli bir hobi olduğunu ve iddia edildiği kadar basit olmayabileceğini kabul etmek bile insanı zaten birçok kişinin önüne geçirir. Umarım projeden çok şey öğrenmiştir.

  • Bir oyun geliştiricisi olarak bu GitHub bana gülünç geliyor. Oyun geliştiricilerinin sevmediği akademik öz-absorpsiyonun bir parodisine yakın. Çirkin ekran görüntüleri de işin tuzu biberi olmuş

    • O zaman bu siteye pek uymuyor denemez mi? Hacker News genel olarak ilginç yeni fikirlerin konuşulduğu bir yer; sadece C++ ve Unity’deki kademeli iyileştirmelerin değil.
      Bu tür tuhaf akademik öz-absorpsiyondan çıkmış birkaç oyun aklıma geliyor. Kardeş yorumdaki Jonathan Blow da öyle; bu projeyi görür görmez aklıma Braid geldi.
      Prosedürel üretim de eskiden fildişi kule konusu sayılırdı; 3D grafiklerdeki tüm ilerlemeler de başlangıçta konferanslardan çıkan, tamamen gerçek dışı görünen makalelerle başladı. Bugün oyunlarda ana akım olan pek çok şey bir zamanlar niş akademik fikirlerdi
    • Ekran görüntülerinin “çirkin” olduğunu düşünmüyorum ama README’nin işlevsel olarak işe yaramaz olduğuna katılıyorum. Dokümantasyon yok, örnek yok, neden kullanılması gerektiğine dair açıklama yok.
      Ne yaptığını aktarmanın en temel aşamasında başarısız oluyor
    • Zihinsel olarak uyarıcı bir şeyler yapmanın da değeri var. Clojure datomics’i oluşturmaya 100 saat harcayıp sadece 1 saatlik seviye içeriği üretsen bile, 1 saat 0 saatten büyüktür.
      Sıkılıp hiç yapmayacak olsaydın bu aslında kazançtır. Bağımsız geliştirmede Jonathan Blow’un Jai kullanma mantığına benziyor
    • Deneysel olduğu yazıyor zaten

  • Bu deponun dokümantasyonu bu kadar az olmasına rağmen epey sohbet çıkmasına şaşırdım. Koda bakınca bir oyun motorundan çok bir proje gibi görünüyor.
    property editor ilginç ama bu gönderi içerikten çok başlığı yüzünden öneriliyor gibi

  • Güzel. Benim gibi Clojure ile oyun geliştiren bir geliştirici görmek sevindirici. Bazen kendi işimi daha da zorlaştırıyorum gerçi :)
    Şu anda Clojure ile 3D çok oyunculu bir TPS shooter geliştiriyorum. İlgilenen olursa demo burada: https://prototype-game.pages.dev
    Yakında geliştirme yolculuğumu anlatan bir blog yazısı da yayımlayacağım

    • Birden fazla kişinin sanal bir alana girip anında koşuşturmaya başlaması ve oyun içi sohbeti kullanması, internette en sevdiğim sahnelerden biri

  • Clojure’u seviyorum ama değişmez veri yapıları kullanan işlevsel bir dil video oyunu geliştirme için biraz tuhaf bir seçim değil mi?

    • Gayet mümkün ve ilginç ödünleşimleri var.
      İşlevsel oyun geliştirmeyle ilgili sevdiğim yazılar şunlar:
      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
    • Oldukça doğal hissettiriyor. Clojure JVM tabanlı olduğu için bu proje içeride libgdx kullanıyor, tüm platformlara dağıtılabiliyor ve kütüphane ekosistemi de büyük.
      Geri kalanında Lisp ile neredeyse her şeyi yapabilirsiniz. Clojure’un değişmez veri yapılarını ele alma biçimi ve harika protocol sistemi (https://www.freshcodeit.com/blog/clojure-protocols-and-the-e...) sayesinde tüm oyunu ayrı bileşenlere kolayca bölebildim
    • Tim Sweeney de UEFN’de Verse ile sanırım bu yöne oynuyor. Verse daha çok Haskell’i daha erişilebilir hâle getiren bir şeye benziyor
    • O kadar da tuhaf değil. Bir sonraki AA ya da AAA oyun bunu kullanmaz ama React’in reducer’ları veya Redux gibi son derece etkileşimli alanlarda da değişmezlik sık görülüyor.
      Clojure’un performans potansiyeli Ruby veya Python’dan daha iyi; ikisi de ticari bağımsız oyunlarda fiilen kullanılmıştı
    • İşlevsel programlama oyun geliştirmede neredeyse doğru dürüst denenmedi bile. Oyun geliştirme sektörüyle akademinin kesişimi yetersiz.
      Stüdyolar doğal olarak riskten kaçınıyor ve nesne yönelimli programlama ya da büyük yığınlar için ECS kullanmak gibi alışılmış stratejileri tercih ediyor.
      Kişisel olarak işlevsel programlamanın iyi uyabileceğini düşünüyorum ama önce gerçek oyun geliştirme problemlerini çözen bir mimari bulmak gerekiyor. Küçük deneylerle başlamak lazım; game jam’ler de bunun için biçilmiş kaftan

  • Unreal Engine 4 üzerinde çalışan Core adlı ticari bir oyun yapım platformu zaten var.
    https://en.wikipedia.org/wiki/Core_(video_game)

  • Bence adı kötü seçilmiş. Bu alanda zaten kullanılıyor: https://www.coregames.com/create

    • Benim de aklıma ilk o geldi. Özellikle de o tarafta oyun içinde oyun yapıldığı için, oyun yazmanın “yeni” bir yolu olarak da görülebilir

  • “Oyun motoruna harcanan zaman/karmaşıklık” ile “ortaya çıkan oyunun karmaşıklığı/ilginçliği” verilerini analiz etmek ilginç olurdu.
    Bir oyun geliştiricisi olarak, basit şablon/motor sistemlerinden çıkan yeni oyunların getirisinin azalan bir logaritmik eğri olacağını tahmin ediyorum.
    Başka bir deyişle, kurabiye basma makinesini ne kadar iyileştirirseniz kurabiyelerin çeşitliliği o kadar azalır