वीडियो गेम लिखने के लिए प्रयोगात्मक नई तकनीक Core

 (github.com/damn)
2 पॉइंट द्वारा GN⁺ 2024-09-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें

  • coreCore क्या है

    • coreCore वीडियो गेम लिखने का एक प्रयोगात्मक तरीका है, जो Action-RPG गेम निर्माण टूल, इंजन और property editor के रूप में काम करता है
    • यह एक सरल component system का उपयोग करता है, और components [keyword value] रूप के clojure vectors होते हैं
    • विभिन्न entities clojure maps से बनी होती हैं
    • गेम के भीतर side effects को [:tx/foo param] जैसे components से संभाला जाता है, जो datomic structure जैसा है
    • पूरे गेम की state app/state नाम के एक atom में स्टोर होती है, और entities भी main atom के भीतर atom के रूप में मौजूद रहती हैं
    • application की पूरी सामग्री resources/properties.edn में स्टोर होती है, जिसे malli-schemas के जरिए validate किया जाता है और GUI से edit किया जा सकता है

  • स्क्रीनशॉट

  • विकास शुरू करने का तरीका

    • नीचे दिया गया command चलाएँ:
      • lein dev
    • application शुरू होगा और साथ में ये काम भी करेगा:
      • NREPL-server शुरू करना
      • application बंद होने पर (main menu में ESC), clojure.tools.namespace बदली हुई files को refresh करता है और app को restart करता है
      • error होने पर JVM को restart करने की ज़रूरत नहीं; error ठीक करके dev-loop/restart! कॉल करें
      • VIM में F5 key पर यह command bind करके इस्तेमाल किया जा सकता है: nmap <F5> :Eval (do (in-ns 'dev-loop)(restart!))

  • कोड लाइसेंस

    • MIT लाइसेंस के तहत उपलब्ध

  • एसेट लाइसेंस

GN⁺ का सार

  • coreCore ऐसा टूल है जो Action-RPG गेम को आसानी से बनाने देता है और एक सरल component system से गेम state को मैनेज करता है
  • पूरे गेम की state को एक atom में स्टोर किया जाता है, और GUI के जरिए properties edit की जा सकती हैं, इसलिए यह developers के लिए उपयोगी है
  • यह MIT लाइसेंस के तहत उपलब्ध है, लेकिन इस्तेमाल किए गए assets proprietary हैं
  • समान फीचर्स वाले tools में RPG Maker, Unity आदि शामिल हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-09-09
Hacker News की राय

  • बढ़िया। मैंने कभी गेम रिलीज़ नहीं किया है, लेकिन गेम डेवलपमेंट के अलग-अलग approaches देखना मुझे हमेशा पसंद है
    अब तक Bevy शुरुआत में अच्छा लगता था, लेकिन implementation में कई समस्याएँ थीं और यह messy हो सकता था। Unity में gameobject और compositional component वाला तरीका सबसे व्यावहारिक लगा, क्योंकि engine रास्ते में नहीं आता और spaghetti से बचना आसान था
    Godot मुझे पसंद नहीं आया। object-oriented की खराब hierarchy, कमजोर built-in language, और spaghetti घटाने के लिए बने “signals” ने उल्टा उसे और बढ़ा दिया। Pygame छोटे projects के लिए काफ़ी अच्छा है, और procedural आधार पर आप object-oriented या functional layers खुद चढ़ा सकते हैं
    Clojure के बारे में मुझे नहीं पता, लेकिन जिस क्षेत्र में आम तौर पर object-oriented approach अच्छी फिट लगती है, वहाँ functional implementation आज़माना दिलचस्प है

    • Unity और Godot दोनों से असली products बना चुके professional game developer के रूप में, Godot और Unity पर इस assessment से बिल्कुल सहमत होना मुश्किल है
      Godot के signals, Unity की built-in classes में modularity की कमी की तुलना में बड़ा सुधार हैं। Godot और Unity मूलतः एक ही scene/node/component model रखते हैं, लेकिन मेरे हिसाब से Godot इसे बेहतर करता है
      Unity की खूबियाँ 3D renderer, built-in PhysX, C# के लिए il2cpp backend, profiler, कुल runtime performance और console support हैं। दूसरी ओर Godot का design ज़्यादा cohesive है, जबकि Unity करीब 2018 से 10 दिशाओं में बिखरता हुआ लगता है
    • मैं game developer नहीं हूँ, लेकिन Godot का object-oriented design मेरे इस्तेमाल किए हुए tools में काफ़ी अच्छा था
      आजकल मैं C++ embedded तरफ़ हूँ, इसलिए object-oriented ज़्यादा इस्तेमाल नहीं करता, लेकिन मैंने programming C# से सीखी थी, इसलिए inheritance से परिचित हूँ
    • Godot शानदार है, और मुझे लगता है कि करीब 5 साल बाद यह game making का Blender बन जाएगा। version 4 production में इस्तेमाल लायक है और ज़्यादातर indie projects संभाल सकता है
      Unity जिन क्षेत्रों में आगे है वे “Triple I” और “Double A” स्तर के हैं, क्योंकि उसके 3D/performance features, tools और add-ons बेहतर हैं। AAA projects के लिए दोनों ही सबसे अच्छे विकल्प नहीं हैं
      2D और साधारण 3D games में अब Unity इस्तेमाल करने की वजह नहीं दिखती, और लगता है Godot धीरे-धीरे आगे निकलेगा जबकि Unity का market share लगातार घटेगा
    • commercial developer के तौर पर पहले मैं Unity इस्तेमाल करता था और अब Godot। GD Script और signals पर criticism से मैं सहमत हूँ, और मैं इससे बचने के लिए C# event handling इस्तेमाल करता हूँ
      nodes और editor में bug हैं या features, समझ न आने वाली चीज़ें सबसे ज़्यादा परेशान करती हैं, और शुरुआत में यह “छोटे” projects के लिए बना था, ऐसा एहसास बहुत मजबूत है
      इसलिए editor को मैं scene composition और मोटे तौर पर hierarchy set करने के अलावा लगभग इस्तेमाल नहीं करता। रोज़मर्रा के tools Emacs+C# LSP हैं, debugging के लिए VS Code, और scene tree adjust करने के लिए Godot editor इस्तेमाल करता हूँ
    • मैंने Godot को काफ़ी गंभीरता से इस्तेमाल किया है और उसे नापसंद करने की वजहें भी हैं, लेकिन मुझे नहीं लगता कि GDScript उनमें से एक है
      यह मूलतः Python में slot/emit semantics जोड़कर editor के साथ integrate किया हुआ रूप है, इसलिए उल्टा ठीक ही है। build system, metadata और external config files से integrate करने वाले जटिल तरीकों की तुलना में इसका language के अंदर होना बेहतर है

  • कहते हैं कि game development को simple बना सकते हैं, और फिर Clojure vectors, datomics, atoms, transactions, malli schemas जैसे jargon की भरमार कर देते हैं। कोई समझा सकता है?

    • intro को थोड़ा साफ़ करें तो, Core एक experimental tool है जो action RPG बनाने को सरल करने की कोशिश करता है
      यह game elements और properties को सरल data structures के रूप में represent करता है, और पूरी game state को एक container (app/state) में store करता है ताकि management और updates आसान हों
      साथ ही यह एक GUI देता है जिससे single file (resources/properties.edn) में stored game content edit किया जा सके, ताकि non-programmers के लिए भी access आसान हो। Malli schema से data validation करके content consistency और errors में कमी लाने का लक्ष्य है
    • निष्पक्ष रूप से कहें तो, यह बस पूछ रहा है कि क्या game development simple हो सकता है। जवाब शायद “नहीं” होने की संभावना ज़्यादा है
    • ज़रूरी disclaimer: “simple होना easy होने जैसा नहीं है”: https://www.youtube.com/watch?v=SxdOUGdseq4
      Clojure vector मूलतः list के काफ़ी करीब है। atom immutable data structure की ओर इशारा करने वाला mutable reference है, और इसे खास update semantics वाले pointer की तरह देख सकते हैं
      transaction database transaction जैसा है: कई data structures को साथ में बदलता है, लेकिन सभी operations सफल हों तभी commit करता है; fail होने पर rollback या retry करता है
      Malli schema dynamic typed language में type checking करने का तरीका है, और Datomic immutable data structures पर आधारित non-SQL database implementation है, जो changes को destructively overwrite नहीं करता बल्कि सिर्फ़ append करता है, ताकि past के किसी भी point पर वापस जाकर देखा जा सके
    • Clojure language में built-in state management model है, और यह project उस model को game development पर लागू करने की कोशिश है
      मेरे हिसाब से इस model को सीखने का सबसे अच्छा तरीका Clojure के creator Rich Hickey का “Are we there yet” talk देखना है
    • Clojure vector language में built-in data structure है और [1 2 3] जैसा दिखता है
      मैं इसका इस्तेमाल [:tx/foo 3] जैसे side effects compose करने के लिए करता हूँ, और Datomic की तरह इन्हें transaction कहता हूँ। यहाँ :tx/foo keyword है और component behavior को uniquely identify करता है

  • सच कहूँ तो यह project असल में fail हुआ लगता है। यह over-engineered chaos है और इसमें clear structure नहीं है
    सबसे बड़ी समस्या यह है कि specification बिल्कुल नहीं है। या तो game story बनाई नहीं गई, या शायद सोचा गया कि game को story की ज़रूरत नहीं है। इसलिए बस Clojure में coding मज़ेदार लगी और पागलों की तरह code कर दिया

    • निष्पक्ष रूप से देखें तो सफल projects में भी कई ऐसे होते हैं जो over-engineered chaos होते हैं और जिनमें clear structure नहीं होता
      कुछ cool try करना अच्छी बात है, और यह ऐसा area है जिसमें बहुत लोगों की दिलचस्पी है
    • सिर्फ़ यह मान लेना कि यह एक मज़ेदार hobby थी और शायद जितना दावा किया गया उतना simple नहीं है, कई लोगों से पहले ही आगे होने जैसा है। उम्मीद है project से बहुत कुछ सीखा होगा

  • गेम डेवलपर के तौर पर यह GitHub मुझे हास्यास्पद लगता है। यह उन अकादमिक आत्ममुग्धता की पैरोडी जैसा है जिसे गेम डेवलपर नापसंद करते हैं। ऊपर से बदसूरत screenshots इसे पूरा कर देते हैं

    • तो क्या यह साइट के लिए ठीक फिट नहीं है? Hacker News आम तौर पर दिलचस्प नए ideas पर चर्चा करने की जगह है, सिर्फ C++ और Unity के incremental improvements की नहीं
      ऐसी अजीब अकादमिक आत्ममुग्धता से निकले कुछ games भी याद आते हैं। sibling comment में Jonathan Blow भी है, और यह project देखते ही मुझे Braid याद आया
      Procedural generation भी पहले ivory tower वाला विषय था, और 3D graphics की हर advancement शुरू में conferences से निकले पूरी तरह अव्यावहारिक papers से शुरू हुई थी। आज games में mainstream बनी कई चीजें कभी niche academic ideas थीं
    • मुझे screenshots “बदसूरत” नहीं लगते, लेकिन इस बात से सहमत हूं कि README functional तौर पर बेकार है। न docs हैं, न examples, और न यह explanation कि इसे क्यों इस्तेमाल करना चाहिए
      यह क्या करता है, यह बताने के बुनियादी चरण में ही असफल है
    • intellectually stimulating चीज बनाना भी valuable है। अगर आप Clojure datomics बनाने में 100 घंटे लगाते हैं और level content सिर्फ 1 घंटे का बनाते हैं, तो 1 घंटा 0 घंटे से बड़ा है
      अगर boredom की वजह से आप कुछ बनाते ही नहीं, तो यह उल्टा फायदा ही है। Indie development में Jonathan Blow के Jai इस्तेमाल करने वाले logic जैसा है
    • इसमें experimental लिखा तो है

  • हैरानी है कि इस repository के docs इतने कम होने के बावजूद काफी बातचीत निकली। code देखने पर यह game engine से ज्यादा एक project जैसा लगता है
    property editor दिलचस्प है, लेकिन लगता है इस post को content से ज्यादा title की वजह से upvotes मिल रहे हैं

  • अच्छा है। मेरी तरह Clojure में game development करने वाले developer को देखकर खुशी हुई। कभी-कभी हम खुद अपना काम ज्यादा मुश्किल बना लेते हैं :)
    अभी मैं Clojure में 3D multiplayer TPS shooter develop कर रहा हूं। interest हो तो demo यहां है: https://prototype-game.pages.dev
    जल्द ही development journey पर blog post भी डालने वाला हूं

    • जब कई लोग virtual space में आते हैं, तुरंत इधर-उधर दौड़ते हैं और in-game chat इस्तेमाल करते हैं, वह internet पर मेरे पसंदीदा moments में से एक है

  • मुझे Clojure पसंद है, लेकिन immutable data structures इस्तेमाल करने वाली functional language वीडियो गेम development के लिए थोड़ी अजीब choice नहीं है?

    • यह बिल्कुल possible है, और इसमें interesting trade-offs हैं
      functional game development से जुड़े मेरे पसंदीदा लेख ये हैं:
      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
    • यह काफी natural लगता है। Clojure JVM-based है, इसलिए यह project internally libgdx इस्तेमाल करता है, सभी platforms पर deploy हो सकता है, और libraries भी बड़ी हैं
      बाकी, Lisp से आप लगभग कुछ भी कर सकते हैं। Clojure की immutable data structures handle करने की शैली और बेहतरीन protocol system(https://www.freshcodeit.com/blog/clojure-protocols-and-the-e...) की वजह से पूरा game अलग-अलग components में आसानी से बांट पाया
    • Tim Sweeney भी UEFN में Verse के जरिए शायद इसी दिशा पर दांव लगा रहे हैं। Verse, Haskell को ज्यादा approachable बनाने जैसा है
    • यह इतना अजीब नहीं है। अगला AA या AAA game इसका इस्तेमाल नहीं करेगा, लेकिन React के reducer या Redux जैसे बहुत interactive domains में भी immutability अक्सर दिखती है
      Clojure में Ruby या Python से बेहतर performance potential है, और दोनों ही commercial indie games में सचमुच इस्तेमाल हो चुके हैं
    • functional programming को game development में ढंग से आजमाया ही बहुत कम गया है। game development industry और academia के बीच overlap कम है
      studios स्वाभाविक रूप से risk-averse होते हैं, और object-oriented या बड़े swarms के लिए ECS जैसी परिचित strategies पसंद करते हैं
      personally मुझे लगता है कि functional programming अच्छी fit हो सकती है, लेकिन पहले ऐसा architecture ढूंढना होगा जो real game development problems solve करे। शुरुआत छोटे experiments से करनी होगी, और game jams इसके लिए perfect हैं

  • Unreal Engine 4 पर चलने वाला Core नाम का commercial game creation platform पहले से मौजूद है
    https://en.wikipedia.org/wiki/Core_(video_game)

  • लगता है नाम गलत चुना गया है। इसी space में यह पहले से इस्तेमाल हो रहा है: https://www.coregames.com/create

    • मेरे मन में भी सबसे पहले यही आया। खासकर क्योंकि वह games के अंदर games बनाने वाला platform है, इसलिए उसे games लिखने का “नया” तरीका भी माना जा सकता है

  • “game engine पर लगाए गए time/complexity” और “निकले game की complexity/interestingness” के data का analysis करना interesting होगा
    game developer के तौर पर, मेरा अनुमान है कि simple template/engine systems से निकलने वाले नए games का payoff diminishing log curve जैसा होगा
    दूसरे शब्दों में, cookie बनाने वाली machine जितनी बेहतर बनाते जाते हैं, cookies की variety उतनी घटती जाती है