Tramway SDK – Half-Life और Morrowind इंजनों का अपवित्र मेल

 (racenis.github.io)
2 पॉइंट द्वारा GN⁺ 2025-01-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Tramway SDK पिछले 3 वर्षों से विकसित किया जा रहा एक graphics package/framework/game engine है, जिसका लक्ष्य mainstream engines की ऊँची system requirements और monolithic editor flow के खिलाफ एक lightweight engine बनना है
  • Unity और Godot जैसे mainstream engines को साधारण low-poly games के लिए भी जरूरत से ज्यादा hardware मांगने वाला माना गया है, इसलिए यह हाल के 15 वर्षों के भीतर के hardware और software rasterization तक को run target बनाता है
  • बनाने का तरीका node GUI और code के बीच आने-जाने के बजाय Entity class inheritance से code लिखने और सिर्फ जरूरी editors चुनकर इस्तेमाल करने की संरचना अपनाता है
  • Level creation Quake-style brush workflow पर आधारित है और .map converter, lightmaps, Gouraud shading, और Source-style input/output system का उपयोग करता है
  • इसका लक्ष्य open-world streaming और 3D RPG Maker के करीब RPG framework है, लेकिन यह अभी early development stage में है, इसलिए API instability और unimplemented elements को ध्यान में रखना होगा

Tramway SDK जिस समस्या को निशाना बनाता है

  • Tramway SDK एक graphics package, framework और game engine है, और “T̈ra̦m̊ẅa̦ÿ SD̈K” जैसी heavy metal-style notation भी साथ में इस्तेमाल करता है
  • Mainstream engines की आलोचना Turbobloat पर केंद्रित है
    • Unity को बहुत powerful hardware और ज्यादा बिजली मांगने वाला माना गया है
    • Godot को Unity से थोड़ा बेहतर, लेकिन फिर भी अपेक्षाकृत capable hardware की जरूरत वाला माना गया है
    • यह रुख है कि low-poly horror roguelite deckbuilder simulator जैसे games 15 साल पुराने hardware पर भी आराम से चलने चाहिए
  • Tramway SDK दावा करता है कि Turbobloat न होने के कारण यह हाल के 15 वर्षों के भीतर के लगभग सभी hardware पर चल सकता है
    • Graphics card के बिना भी चलने के लिए software rasterization पर switch किया जा सकता है
    • toaster या refrigerator जैसे devices पर graphics दिखाने के उदाहरण तक दिए गए हैं
  • “बेहतर computer खरीद लो” वाली आपत्ति का जवाब तीन कारणों से दिया गया है
    • कई लोगों के पास powerful hardware खरीदने की क्षमता नहीं होती—यह affordability की समस्या है
    • Computer chips का उत्पादन पर्यावरण के लिए खराब है, और अगर software bloated न हो तो नया hardware केवल तब खरीदना चाहिए जब पुराना खराब हो जाए और repair न हो सके—यह e-waste की समस्या है
    • जब पहले से अच्छा चल रहा computer मौजूद है, तो किसी और के Turbobloat की वजह से नया computer खरीदने का कोई कारण नहीं है

बनाने का तरीका और features

  • Node-based creation approach की आलोचना इसलिए की गई है कि इसमें “एक चीज जैसा दिखने वाली कई चीजों” को संभालना पड़ता है और node GUI व code के बीच आना-जाना पड़ता है
  • Tramway SDK में Entity class को inherit करके code लिखा जाता है और फिर level editor से level बनाए जाते हैं
    • Nodes का उपयोग किए बिना entity-centric संरचना अपनाई जाती है
    • Code और node GUI के बीच आने-जाने वाले flow से बचा जाता है
  • Mainstream engines के monolithic editors को भी समस्या माना गया है
    • माना जाता है कि जिन features का इस्तेमाल नहीं करना है, उनके साथ भी पूरा editor load होने का इंतजार करना पड़ता है
    • Tramway SDK के सभी editors optional हैं
    • अगर केवल framework के रूप में इस्तेमाल करना हो, तो सिर्फ C++ runtime का उपयोग किया जा सकता है
    • अगर केवल level creation चाहिए, तो सिर्फ level editor इस्तेमाल किया जा सकता है
    • Data files whitespace-separated values format में होती हैं, इसलिए editor के बिना हाथ से भी बदली जा सकती हैं
  • Graphics के मामले में lightmaps और Gouraud shading भर से भी example images बनाई जा सकती हैं
    • यह example Direct3D 7-level graphics card के fixed-function pipeline पर भी render किया जा सकता है
  • Level creation Quake-family brush-based workflow को support करता है
    • Tramway SDK .map file converter देता है और brushes को triangular mesh में बदलता है
    • Trenchbroom में level बनाकर Tramway SDK level editor में configure करने का flow दिखाया गया है
    • Engine के अंदर lightmapped level render किया जाता है
    • Source जैसा input/output system level के भीतर entities के बीच interactions set करने देता है
    • आगे चलकर पूरे Source logic entity को implement करने की योजना है, ताकि level editor के अंदर visual scripting संभव हो सके
  • RPG के लिहाज से, RPG Maker जैसे tools और Morrowind-based mods/total conversions में कई चीजें data changes से बनाई जा सकती हैं—इसे एक दिलचस्प उदाहरण माना गया है
    • Tramway SDK में 3D के लिए RPG Maker के करीब एक RPG framework extension है
    • Engine को शुरुआत से level streaming support करने के लिए design किया गया है, जिससे open-world RPG-style games बनाना तेज और आसान हो सकता है
  • संक्षेप में, Tramway SDK Quake/Source-style entity-based game engine है और open-world streaming तथा RPG framework जैसे optional extensions देता है
  • Development status अभी बहुत early stage में है
    • API unstable है
    • Features टूट सकते हैं या काम नहीं कर सकते
    • अभी कई elements implement नहीं हुए हैं
    • बताया गया है कि इसमें तेजी से सुधार हो रहा है
  • GitHub repository: racenis/tram-sdk

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

1 टिप्पणियां

 
GN⁺ 2025-01-08
Hacker News की राय

  • कुछ लोग कह सकते हैं “बस बेहतर कंप्यूटर खरीद लो”, लेकिन इसी वजह से मैं पूरी तरह सहमत हूँ कि बेहतर कंप्यूटर खरीदना बुरा है। बहुत से लोग, खासकर विकासशील देशों के लोग, Turbobloat चलाने लायक hardware खरीदने की क्षमता नहीं रखते, और chip production का पर्यावरण पर बुरा असर पड़ता है
    अगर आधुनिक software इतना फूला हुआ न होता, तो लोग नया hardware तभी खरीदते जब मौजूदा hardware खराब हो जाए और repair न हो सके। जब कोई कंप्यूटर ठीक-ठाक चल रहा है, तो किसी और के bloated software की वजह से नया कंप्यूटर खरीदने की कोई वजह नहीं है; उतने पैसों में Dr. Pepper के 1000 cans भी खरीदे जा सकते हैं। यह सच में अच्छा project है, उम्मीद है वे इसकी progress लगातार post करते रहेंगे

    • “320x200 से 800x600 तक की screen resolutions” कहा गया है, लेकिन higher resolutions सिर्फ Turbobloat की वजह से ही invent नहीं हुए थे
    • ऐसा कहते हुए भी engine शायद OpenGL 4 GPU मांगता है, जबकि graphics ऐसे लगते हैं कि Voodoo card पर भी चल सकते हैं
    • मुझे समझ नहीं आया Turbobloat क्या है। context से यह “वह graphics technology जो मुझे पसंद नहीं” जैसा पढ़ता है, लेकिन Turbobloat की सीमा कहाँ तक है, यह साफ नहीं है
    • नया कंप्यूटर बनाना और ship करना लंबे समय में worthwhile हो सकता है। क्योंकि performance और power efficiency में सुधार समय के साथ environmental impact की भरपाई कर सकते हैं
      बेशक अगर बात entertainment की हो तो फैसला मुश्किल है, और कोई पुराना Game Boy शायद 1000W वाले modern gaming PC से भी ज्यादा मजेदार हो सकता है

  • “एक को एक ही होना चाहिए। वह कई चीजें नहीं होनी चाहिए जो एक होने का नाटक करें। nodes का इस्तेमाल करने पर आपको कई चीजों के समूह को एक होने का नाटक कराना पड़ता है” — यह वाक्य सच में Terry Pratchett जैसा लगता है और शानदार है
    मुझे यह इसलिए पसंद है कि Sam Vimes किसी जटिल investigation के दौरान ऐसा सोच सकता था, और उम्मीद है यह आगे विकसित होता रहे। मैंने अभी इसे खुद try नहीं किया है, लेकिन मेरे AI project में इस्तेमाल करने के लिए मेरे पास एक idea है

    • उस वाक्य को अलग से देखें तो उल्टा यह साफ तौर पर गलत नहीं लगता? हम हमेशा कई चीजों के समूह को एक चीज मानते हैं
      इंसान body parts का समूह है, body parts chemicals का समूह हैं, chemicals molecules का समूह हैं, और molecules atoms का समूह हैं, फिर भी हर स्तर पर हम उन्हें एक मानते हैं। ऐसा करने से रोकना बेवकूफी है। फिर भी project अच्छा दिखता है
    • लगता है Sam Vimes ऐसा कहने के बाद Sybil की वजह से painful growth से गुजरेगा और अनिच्छा से मान लेगा कि “कभी-कभी एक को बस एक से ज्यादा भी होना पड़ सकता है”
      और Vetinari का entity component system जटिल दिखता है, लेकिन ठीक से काम करता है और इस धत्त शहर को चलाए रखता है
    • यह line शायद उन लोगों को target करती है जिन्होंने दूसरे solutions try किए और उन्हें नापसंद किया, लेकिन game engine कभी न इस्तेमाल करने वाले व्यक्ति के तौर पर अच्छा होगा अगर कोई आसानी से समझा दे कि nodes का “कई चीजों के समूह को एक होने का नाटक कराना” से क्या संबंध है
      मेरा अंदाजा है कि node editor का user experience Finger के Vector जैसी चीजों को properties और relationships देने के लिए प्रेरित करता है, लेकिन आखिर में Vector सिर्फ “चीजों का समूह” है, अपने behavior वाली कोई “type” नहीं, इसलिए उस पर code attach करना मुश्किल है।
      क्या “सब कुछ Entity है और बस code लिखो” का मतलब यह है कि Vector के बजाय Fingers रखने वाली, अपनी state और behavior वाली Hand class बनाने की तरफ जाना चाहिए? या फिर किसी खास static values और relationship members को पहले से बांधकर node instance बनाने के बजाय, Entity subclass को फिर inherit करके और specific बनाना चाहिए?
    • ठीक अगला paragraph दिलचस्प है: “nodes से कुछ बनाते समय आपको node GUI और code के बीच लगातार आना-जाना पड़ता है”
      Godot की Node/GDScript संरचना को इस दावे का एक तरह का जवाब माना जा सकता है। $ operator और autocomplete जैसी चीजों के जरिए उस “आना-जाना” को जितना हो सके seamless और integrated बनाने की कोशिश है। फिर भी अंत में game release करना होता है, इसलिए मुझे लगता है “एक, एक ही है” वाली सोच आखिरकार जीतती है
    • दुर्भाग्य से, हर चीज उन चीजों का समूह है जो एक होने का नाटक करती हैं, और single चीज भी ऐसी ही है। हम ज्यादा से ज्यादा या तो ऐसा नाटक कर सकते हैं, या पकड़े बिना उससे बच सकते हैं

  • समय बीतने के साथ ऐसा लगता है कि कोई बाहरी ताकत game engine quality को कम कर रही है। टेक्नोलॉजी में आम तौर पर वही चीज़ें व्यापक होती हैं जिनका curriculum बनाना आसान होता है
    Unity जैसे node-based editors को कई classes में समझाने के लिए structure बिल्कुल फिट बैठता है। इसके उलट raylib जैसे engines को एक दोपहर में समझा जा सकता है, इसलिए university level की raylib class बन पाना मुश्किल है। इसी वजह से bootcamp जैसे schools से ऐसे amateur developers निकलते हैं जो सिर्फ Unity/Unreal जानते हैं, companies Unity/Unreal talent hire करती हैं, और universities फिर वही पढ़ाती हैं—ऐसा cycle बन जाता है। यह Java की popularity वाले phenomenon जैसा भी है।
    साथ ही, हर company की Unity project requirements अलग होती हैं, इसलिए Unity को किसी असंतुष्ट programmer की तरह नहीं, बल्कि customers से deal करने वाली for-profit company के रूप में engine को लगातार adjust करना पड़ता है, और अंततः वह Turbobloat बन जाता है। Half-Life और Morrowind engines एक अनोखी situation में बने थे, जहाँ passionate programmers को वे चीज़ें develop करने के लिए पैसे मिल रहे थे जिन्हें वे cool मानते थे; इसलिए professional game developers के लिए उपयुक्त न्यूनतम engine और बेहतरीन technology निकली।
    यह project raylib और Unity के बीच कहीं लगता है। चिंता है कि amateur programmers को appeal करने के लिए यह कम पड़ सकता है, और छोटे engine चाहने वाले programmers के लिए शायद यह बहुत ज़्यादा काम कर रहा हो। उम्मीद है मैं गलत साबित होऊँ; performance और polish अच्छे दिखते हैं। Unity से थके हुए developers निश्चित रूप से हैं, और nostalgia का cycle 2000s की ओर बढ़ने के साथ Half-Life 2 से कम graphically complex games खेलने और बनाने की demand भी सच में है। web design और documentation का tone भी अच्छा है

    • यह भी महत्वपूर्ण है कि जब game और engine साथ-साथ बनाए जाते हैं, तो वे एक-दूसरे के हिसाब से ढल सकते हैं। Doom में एक floor के ऊपर दूसरा floor नहीं रखा जा सकता था; यह CPU constraints से आई engine limitation थी, और level designers ने उसे वैसा दिखाने के लिए tricks बनाए
      दोनों को साथ design करने पर added features का actively इस्तेमाल किया जा सकता है, और जो features अच्छे से नहीं चलते उनसे बचा जा सकता है, या art style को ही engine के हिसाब से ढाला जा सकता है। Minecraft के pixelated, angular mobs engine के साथ अच्छी तरह fit होते हैं, लेकिन अगर उन्हें ज़्यादा refined बनाना शुरू करें, तो जब तक वे पर्याप्त polygons के साथ ठीक से render न होने लगें, वे Minecraft से भी ज़्यादा पुराने और awkward दिखने वाली uncanny valley में गिर जाते हैं
    • मुझे याद है कि Bioshock पर काम कर चुके किसी व्यक्ति ने, शायद lead designer ने, एक interview में कहा था: “company में कोई नया idea experiment करना हो तो team बनानी पड़ती है और कुछ छूने लायक बनने में कम से कम एक महीना लग जाता है। इसके उलट, घर पर एक ही शाम में Doom की पूरी campaign बनाई जा सकती है”
    • मुझे raylib या libgdx जैसी library-based game development पसंद है, लेकिन Slay the Spire जैसे game के sequel में Unity से होकर Godot तक जाने के पीछे वजह है
      मुझे नहीं लगता कि लोग complexity पसंद करने वाले professors से गलत सीखकर Unity इस्तेमाल कर रहे हैं
    • पुराने games सच में crisp थे, लेकिन आजकल के games गड़बड़ चलते हैं, crash होते हैं, download के लिए 150GB चाहिए होता है, और launch होने में 150 साल लगते हैं। अगर हम graphics के लिए games खेलते, तो सबसे popular MMOs में से एक 2002 के browser game पर based नहीं होता, और शुरुआत से ही हम game नहीं बल्कि reality खेल रहे होते
      Epic Games ने Fortnite के साथ जो किया, वही देख लीजिए। smooth चलने वाले competitive scene-centric game को Turbobloat graphics और skins के कारण खत्म कर दिया
    • “ऐसे programmers निकलते हैं जो सिर्फ Unity/Unreal जानते हैं, companies Unity/Unreal talent hire करती हैं, और universities फिर वही पढ़ाती हैं” वाला phenomenon ArcGIS में भी कुछ ऐसा ही दिखता है

  • turbo bloat की समस्या से पूरी तरह सहमत हूँ। आज की machines कहीं ज़्यादा powerful हैं, फिर भी ज़्यादातर programs पहले से धीमे महसूस होते हैं
    project भी बेहद cool है और website design A+ है

    • “ज़्यादातर programs पहले से धीमे हैं” यह बात शायद सिर्फ उन लोगों पर सही बैठती है जिन्हें किसी खास दौर में थोड़े overpowered hardware का इस्तेमाल करने की किस्मत मिली थी
      Windows 98/2000/XP के समय ordinary hardware इस्तेमाल करने वाले के नज़रिए से, SSD वाले low-end modern laptop पर Windows 10/11/KDE/Gnome आदि चलाना—vscode या Slack जैसे bloated माने जाने वाले web apps चलाने पर भी—कहीं ज़्यादा responsive है
    • मुझे Turbobloat term समझ नहीं आती। games बनाए हैं, लेकिन कभी सुना नहीं; author ने भी define नहीं किया है, और Kagi पर search करने पर सिर्फ submitted post आता है, जबकि Google पर related results नहीं हैं
      सोच रहा हूँ कि क्या इसका मतलब बस “बहुत bloated” है। site को और पढ़ने पर “hyperrealistic physics simulation” जैसे expressions भी दिखे, इसलिए लगता है कि आखिरकार इसका मतलब “बहुत ज़्यादा bloat” ही है

  • “ज़्यादातर Unity गेम, भड़कीले shaders, normal mapping और दूसरी तकनीकें इस्तेमाल करने के बावजूद, बहुत खराब दिखते हैं” — यह नज़रिया एक खास पीढ़ी के बीच धीरे-धीरे आम होता दिख रहा है
    यह तय है कि किसी तरह की texture mapping तकनीक गायब हो गई है। Ikaruga का background ज़रूरत से ज़्यादा शानदार है, खासकर शुरुआती हिस्से का साधारण-सा जंगल effect। PS2 दौर के कुछ train simulator भी यह कर पाए थे।
    हालांकि, अगर सूरज जैसा तेज़ directional light source किसी चमकीली object पर पड़े और player हिले, तो यह तरीका टूट जाता है। अगर environment धुंधला हो और dynamic objects बिल्कुल न हों, तो आधुनिक tricks को काफी हद तक bypass किया जा सकता है

    • सही। समस्या यह है कि कुछ modern games धुंधले होते हैं और उनमें dynamic lighting भी नहीं होती, फिर भी वे ज़बरदस्ती Lumen इस्तेमाल करते हैं। Silent Hill remake में ऐसा ही था; वह बहुत धीमा चलता है, PS5 Pro पर और भी खराब दिखता है, और grass भी पुराने games से कमज़ोर लगता है
      मूल Silent Hill की setting असल में optimization tricks को सही ठहराने के लिए बनाई गई थी। स्क्रीन पर objects manage करना आसान हो, इसलिए “fog space” नाम की स्थायी धुंधली जगह रखी गई थी, लेकिन remake ने supernatural दिखने वाली fog के बजाय realistic fog बनाने में बहुत सारी processing बर्बाद कर दी
    • Unity में बने शानदार games “Unity game जैसे” नहीं दिखते, इसलिए लोग उन्हें “Unity game कैसा दिखता है” के उदाहरण के तौर पर याद नहीं करते। इसलिए Unity games की typical छवि लगातार “काफी rough” ही बनी रहती है
      अच्छा दिखाने वाली art skills बिल्कुल गायब नहीं हुई हैं; वे बस बेहद असमान रूप से बंटी हुई हैं। अगर किसी team के पास अच्छे modelers, texture artists, animators और visual programming की क्षमता है, तो game Unreal में हो, Unity में हो या custom engine में—वह शानदार दिख सकता है
    • यह ज़िद रहती है कि materials के दम पर कमजोर texturing और normal mapping की भरपाई की जा सकती है। यह सच नहीं है; यह Unreal Engine जैसी चीज़ों की marketing copy को गलत समझने या तोड़-मरोड़ देने का नतीजा है
      Super Mario Sunshine में GameCube जिन “sharp” shadows को render नहीं कर सकता था, उनके लिए असल में flat mesh इस्तेमाल हुआ था। Delfino Plaza में Shine Gate के पास awning के नीचे की shadow texture नहीं, बल्कि mesh है। वहीं जिस tiled plaza पर वह mesh shadow पड़ी है, वह इसलिए अच्छा दिखता है क्योंकि वहाँ एक विशाल texture नहीं, बल्कि दर्जनों 128x128px textures को सही तरीके से UV map किया गया है।
      कोई modern game होता तो दो brick textures और उन्हें mix करने के लिए noise pattern इस्तेमाल करता, और तीनों 2048x2048px के होते; shadows ray tracing से sharp edges बनातीं। विडंबना यह है कि VRAM और bus speed बढ़ने के बावजूद हमने ज़्यादा textures के बजाय बड़े textures चुन लिए। normal mapping के साथ भी यही है: इसे ज़्यादा subdivided models के साथ इस्तेमाल करने के बजाय यह गलतफहमी है कि normal maps पुराने हो गए हैं और सारी details को सचमुच model करना ही technically advanced रास्ता है। कम angular sphere ठीक है, लेकिन sphere की हर दरार और खरोंच को सचमुच model करना बेवकूफी और compute की बर्बादी है
    • Unity जैसी चीज़ों से कुछ working चीज़ काफी जल्दी बनाई जा सकती है, लेकिन उसे सच में शानदार दिखाने के लिए अलग skills और polish चाहिए
      Factorio जैसे “2D” game में भी initial release, 1.0 और current version के बीच polishing का फर्क बहुत बड़ा है। modded game में भी यह फर्क साफ दिखता है; mod assets आम तौर पर “कामचलाऊ” होते हैं, लेकिन main game जितने polished नहीं दिखते

  • हाल ही में Half-Life 2 फिर से खेला, और high-resolution texture pack के बिना भी यह आज कितना शानदार दिखता है, देखकर हैरानी हुई

    • मुझे लगता है कि इसकी वजह game का art style बेहद समझदारी से चुनना है। इसमें बहुत सारे diffuse surfaces हैं जिन पर pre-baked lighting अच्छी तरह काम करती है, और cloudy sky directional lighting की जगह फैला हुआ ambient light देता है, जो angle-dependent shading और sharp high-contrast shadow outlines को मजबूर नहीं करता
      चमकीली surfaces भी ज़्यादातर बहुत ज़्यादा glossy नहीं हैं, जिससे मदद मिलती है। ये choices एक पुराने, कब्ज़े में लिए गए extreme dystopian world के साथ अच्छी तरह फिट होती हैं और believable लगती हैं, जबकि muted colors वाली textures पूरी चीज़ को एकजुट रखती हैं
    • इसलिए मुझे लगता है कि सच में अच्छी art direction हमेशा raw graphics performance को मात देती है। Source अपने समय में भी impressive था, लेकिन जो हिस्सा टिक पाया वह यह है कि environments और models कितनी सावधानी से design किए गए थे
      Valve ने technical constraints के भीतर details डालने और उनसे अधिकतम निकालने पर resources लगाए, और 20 साल बाद भी यह cohesive और well-designed दिखता है
    • Half-Life 2 को release के बाद shading और detail levels में कई updates मिले, इसलिए यह launch के समय की तुलना में थोड़ा बेहतर दिखता है। फिर भी release के वक्त भी यह visually impressive game था
    • एक हफ्ते से भी कम समय पहले Half-Life 2 फिर से खेला, और मुझे लगा कि “levels modern games जितने details से भरे नहीं हैं, फिर भी graphics और level design की artistic direction बड़े budget वाले कई modern designers से बेहतर है”
    • HL1 को HL2 engine में remake करने वाला Black Mesa भी खेलने लायक है। मैंने pandemic के दौरान खेला था और कोई पछतावा नहीं हुआ

  • Godot में low poly game बनाने वाली एक छोटी team में काम करने के नाते, यह अच्छा लगा
    “nodes से कुछ बनाते समय node GUI और code के बीच लगातार आना-जाना पड़ता है”, “mainstream engines में एक विशाल monolithic game editor होता है, और कोई भी feature इस्तेमाल करें, सब कुछ load होने तक 10 मिनट इंतज़ार करना पड़ता है” — ये बातें बहुत relate हुईं। Godot में भी मैं flashy features लगभग इस्तेमाल नहीं करता, फिर भी debug loop मुझे दूसरे environments में programming करने की तुलना में काफी धीमा लगा।
    एक data file specification के इर्द-गिर्द कई editors के साथ काम करने का idea भी अच्छा है। integrated IDE कई developers के लिए merge conflicts बनाना आसान कर देता है, इसलिए ज़्यादा specific-purpose editors role-based developers को changes की scope और nature सीमित रखने में भी मदद कर सकते हैं। engine कैसे आगे बढ़ेगा, यह देखने की उत्सुकता है

    • पिछले महीने hackathon में Unity चलाए बिना C# modules को test-driven development से बनाने का तरीका निकाल लेने पर मुझे काफी गर्व हुआ
      कम performance वाले netbook से भी मैं अपना योगदान दे सका। मैंने C# की एक भी line पहले नहीं लिखी थी, लेकिन command line पर TDD छोड़ने का कोई इरादा नहीं था। मुझे पता चला कि यह संभव है और आखिरकार इसे काम करा लिया। सबको लगा मैं पागल हूँ, और sponsor के developer relations वाले भी कोई मदद नहीं कर पाए।
      उस weekend की सबसे बड़ी friction अब भी यही थी कि सबसे अच्छे computer को भी उस कमबख्त Unity IDE को खोलने और फिर से खोलने में युगों जितना समय गंवाना पड़ता था। लोग जिन बेड़ियों को सह लेते हैं, वह हैरान करने वाला है

  • “Turbobloat” और engine के “bloated” होने की बात की गई है, और कुछ हद तक यह सही है। लेकिन यह बताना ठीक रहेगा कि इसका उनके लिए क्या मतलब है, किन features को वे bloat मानते हैं, और Tramway project से क्या हटाया गया है
    उदाहरण के लिए, कुछ लोगों को RPG framework शामिल करना भी bloat लग सकता है, जबकि Tramway में वह मौजूद है

    • इसलिए उसे optional extension के रूप में डाला गया है। यह बड़े engine project का हिस्सा तो है, लेकिन पूरी तरह optional है
      मुझे C++ का “केवल उसी चीज़ की कीमत चुकाओ जिसे इस्तेमाल करते हो” वाला सिद्धांत पसंद है

  • लिखा है कि यह “उन beginners के लिए framework इस्तेमाल करने का तरीका है जिन्हें C++ से डर लगता है या जो बस इसमें अच्छे नहीं हैं”; मैं दूसरी category में आता हूँ, और Getting Started पेज के लिए आभारी महसूस हुआ
    चायदान दिखा, और जिन चीज़ों को मैं समझ नहीं पाऊँगा सोच रहा था, उन्हें समझ गया। अभी lunch break में सिर्फ 30 मिनट हैं, इसलिए tutorial पूरा करने का समय नहीं है, लेकिन इसे जारी रखने का मन हो गया—यह अच्छी तरह दिखाता है कि यह document कितना मज़ेदार और approachable है

  • क्या किसी को Design Patterns पेज मिला? यह 100% target वाला scoreboard है, और मुझे बहुत पसंद आया

    • Home page पर link है: “इस्तेमाल किए गए design patterns 82%। जब सभी patterns इस्तेमाल हो जाएंगे, तो project delete करके Rust में फिर से लिखूंगा। Object-oriented के बिना”
    • काफी देर तक ढूंढा, फिर भी अभी तक नहीं मिला