- commercial game engine के बिना भी गेम डेवलपमेंट काफ़ी आसान और मज़ेदार तरीके से किया जा सकता है
- बड़े इंजनों के ज़्यादातर फीचर्स की ज़रूरत नहीं होती, और अपने टूल खुद लिखने से लचीलापन और डेवलपमेंट दक्षता बढ़ती है
- modern C# और open source libraries का उपयोग करके टीम के आकार की परवाह किए बिना पर्याप्त डेवलपमेंट एनवायरनमेंट बनाया जा सकता है
- FMOD, SDL3, Dear ImGui जैसी लाइब्रेरी और अपने टूल्स को मिलाकर ज़रूरत के मुताबिक पाइपलाइन बनाई जा सकती है
- cross-platform development, maintenance, portability के लिहाज़ से खुद बनाया गया lightweight framework बहुत फ़ायदेमंद होता है
प्रस्तावना: 20 साल के गेम डेवलपर की बातें
- 2025 में भी मैं commercial game engine के बिना वीडियो गेम डेवलप कर रहा हूँ
- आसपास के लोग अक्सर इस बात पर हैरान होते हैं कि मैं commercial engine का उपयोग नहीं करता
- Unity या Unreal जैसे बड़े इंजनों के बेसिक फीचर्स, उन्हें खुद इम्प्लीमेंट करने की तुलना में संतोषजनक नहीं लगते, और अंत में कई हिस्से फिर से बनाने पड़ते हैं
- commercial engine का उपयोग करने पर बार-बार होने वाले business policy changes या updates से पैदा होने वाली समस्याओं का सामना करना पड़ता है
- हर प्रोजेक्ट के लिए बिल्कुल फिट बैठने वाले छोटे टूल्स खुद बनाना ज़्यादा कुशल है, और लंबे समय में maintenance भी आसान रहता है
गेम डेवलपमेंट के लिए प्रोग्रामिंग भाषा का चुनाव
- लंबे समय से C# को मुख्य भाषा के रूप में उपयोग किया है
- modern C# में पहले की तुलना में performance, syntax, developer experience काफ़ी बेहतर हुए हैं
- dotnet watch जैसी hot reload सुविधा होने से real-time code changes और testing बहुत सुविधाजनक हो जाती है
- non-developers के लिए भी इसे अपनाना आसान है, इसलिए टीम में role division और collaboration efficiency बढ़ती है
- built-in reflection फीचर editor या tools बनाने में बड़ी ताकत देता है
cross-platform libraries और rendering/input implementation
- SDL3 का उपयोग करके window, rendering, controller, cross-platform support जैसी सभी बुनियादी सुविधाएँ इम्प्लीमेंट की जाती हैं
- SDL3 की GPU abstraction की वजह से DirectX, Vulkan, Metal जैसे अलग-अलग environments को support करना आसान हो गया है
- SDL के ऊपर लिखी गई अपनी C# layer (जैसे Foster) को common utility के रूप में उपयोग किया जाता है
- FMOD को आख़िरी बचा हुआ commercial audio tool के रूप में उपयोग किया जाता है, बाकी pipeline open source आधारित है
- पहले OpenGL/DirectX को सीधे इम्प्लीमेंट करने का अनुभव भी रहा है, लेकिन SDL की stability एक बड़ा फ़ायदा है
assets को संभालने का तरीका
- अपना इंजन इस्तेमाल करने पर गेम में ज़रूरी फ़ाइलों को ही सरल तरीके से लोड किया जाता है
- pixel art गेम जैसे छोटे assets वाले मामलों में initialization के समय सभी फ़ाइलें एक साथ लोड कर ली जाती हैं
- बड़े प्रोजेक्ट्स में केवल ज़रूरत पड़ने पर assets लोड किए जाते हैं, और scene change के समय memory free की जाती है
- अगर conversion की ज़रूरत हो तो compile समय automatic processing scripts लिखना काफ़ी होता है
level editor और UI tools
- LDtk, Tiled, Trenchbroom जैसे open source level editors के साथ data integration आसान है
- ज़्यादातर मामलों में हर प्रोजेक्ट के लिए custom editor सीधे इम्प्लीमेंट किया जाता है
- UI का मुख्य ढाँचा खुद लिखने के बजाय Dear ImGui के immediate-mode GUI का सक्रिय रूप से उपयोग किया जाता है
- C# के reflection और ImGui के संयोजन से game object state को real-time में visualize किया जा सकता है
- ज़रूरत पड़ने पर उपयुक्त external tools और अपने tools को मिलाकर उपयोग किया जाता है
cross-platform और console portability
- पहले console porting की समस्याओं के कारण C++ चुनने की ज़रूरत ज़्यादा थी, लेकिन C# Native-AOT आने के बाद यह काफी हद तक हल हो गया है
- FNA जैसे open source frameworks में console support को सक्रिय रूप से बढ़ाया जा रहा है
- SDL3 द्वारा दिए गए generic abstraction layer का उपयोग करने पर ज़्यादातर systems में एक ही codebase चलाया जा सकता है
डेवलपमेंट एनवायरनमेंट: Linux-केंद्रित open ecosystem
- मुख्य डेवलपमेंट प्लेटफ़ॉर्म को Linux पर शिफ्ट किया गया है, और इसका open source toolchain के साथ तालमेल बहुत अच्छा है
- कुछ specific commercial software से जुड़ाव अभी भी है (जैसे vscode, github), लेकिन open source ecosystem जितना फैलता है, support भी उतना बढ़ता है
- व्यक्तिगत रूप से Steam Deck जैसे अलग-अलग Linux-आधारित platforms पर भी वही work environment बनाया जा रहा है
अतिरिक्त Q&A और उदाहरण
- Godot के उपयोग पर सवाल: अगर open source engine-केंद्रित डेवलपमेंट की ज़रूरत हो तो Godot की सिफारिश, अन्यथा custom tools को प्राथमिकता दी जाती है
- 3D काम: बड़े इंजनों के अपने फ़ायदे हैं, लेकिन छोटे और विशेष प्रोजेक्ट्स के लिए custom framework काफ़ी है
- high-performance तकनीकी ज़रूरतें: आवश्यकता के स्तर के अनुसार Unreal जैसे बड़े engine का उपयोग भी ठीक है
- टीम स्तर पर इंजन बदलना: यह छोटे पैमाने/solo development के लिए उपयुक्त है, और medium/large studios में भी long-term risk avoidance के लिए custom engine अपनाने के उदाहरण बढ़ रहे हैं
- asset workflow: Aseprite फ़ाइलों को built-in tags और timing का उपयोग करके अपने-आप animation में बदला जा सकता है
निष्कर्ष
- commercial game engine के बिना गेम बनाना पसंद और काम करने के तरीके पर निर्भर एक चुनाव है
- ज़रूरत और मज़े को सबसे ऊपर रखकर अपने लिए सही तरीका चुनना चाहिए
5 टिप्पणियां
यह बहुत अच्छी पहल है.
मैं पहली पीढ़ी का गेम डेवलपर था.
Unreal के आने से पहले, स्वाभाविक रूप से डेवलपमेंट कंपनियों के लिए
अपना इंजन बनाना आम बात थी,
और वही उनकी प्रतिस्पर्धात्मक ताकत भी होती थी.
इंजन डेवलपमेंट में core, kernel, rendering और अन्य input/output को
आधार बनाकर tool development का सबसे बड़ा हिस्सा होता था.
मैं उस समय particle, sound, layer और object tools का
जिम्मा संभालता था,
और हमारी टीम 7 लोगों की थी, लेकिन सबको मिलाकर देखें तो 20 से भी अधिक tools
आराम से हो जाते थे, ऐसा लगता है.
फिर एक समय ऐसा आया जब Unreal सामने आया और बड़े पैमाने पर बनने वाले गेम
तेज़ी से आने लगे, तो उसके बाद इंजन डेवलपमेंट में निवेश नहीं किया गया.
लगता है उसी समय बहुत से लोगों ने स्वतंत्र होकर अपनी कंपनियां शुरू की थीं.
यह बात अब 27 साल पुरानी हो गई है.
मैं भी अब उम्रदराज़ हो चुका हूँ और गेम्स के बजाय किसी दूसरे काम में हूँ.
ग्राफिक्स कार्ड के हिसाब से directx और opengl मोड के लिए
core पर काम करने वाले वे धुंधले लेकिन प्यारे दिन याद आते हैं.
गंबारेयो...
हाल ही में मैं एक strategy game बनाने के लिए लंबे समय तक कोई engine ढूंढ़ता रहा, और तब लगा कि अगर ऐसा ही है तो खुद ही एक बना लेना बेहतर होगा। लेकिन इसे सच में करके सफल हुए उदाहरण को देखकर हिम्मत उमड़ पड़ी।
Hacker News राय
5 साल तक अकेले 2D गेम इंजन विकसित करने और उससे जुड़े paid काम करने के दौरान मैं कुछ ऐसे महत्वपूर्ण बिंदु बताना चाहता हूँ जिन पर लोग अक्सर ध्यान नहीं देते
इंजन आसान हिस्सा है
वास्तव में महत्वपूर्ण चीज़ इंजन के आसपास की tooling, content, और asset pipeline है
विभिन्न data source और format से texture, audio, model file (
gltf,fbx, animation आदि) import करनाeditor app में cut, copy, paste, undo, redo, save, delete जैसी बुनियादी editing सुविधाएँ
ऐसी visualization और functionality जो developer को editor में वास्तविक data बनाने और manipulate करने दे (entity, animation, scene, audio graph, scripting support आदि)
static geometry baking, shader compilation, texture·audio resampling और packing, game content asset pack बनाना जैसी data packaging और preprocessing
ये सब हो जाने के बाद वास्तविक runtime हिस्सा (यानी game main loop और उसके subsystems) पूरे system का छोटा हिस्सा ही होता है
इसीलिए game studio में engine पर काम करने वाले कम होते हैं, जबकि tools बनाने वाले programmer ज़्यादा होते हैं
detonator इंजन: https://github.com/ensisoft/detonator
general-purpose होने से ज़्यादा अपने game के लिए उपयुक्त इंजन बनाने पर ध्यान देना महत्वपूर्ण है
UI, compression आदि को library और framework से हल किया जा सकता है
OP का imGUI जैसी छोटी library का उपयोग करना इसका अच्छा उदाहरण है
जब आप हर तरह के game के लिए इंजन नहीं बना रहे होते, तो बहुत सा काम अपने आप अनावश्यक हो जाता है
इंजन asset pipeline से जुड़ा एक छोटा runtime addon जैसा होता है
आजकल shader compiler, 3D API से भी ज़्यादा महत्वपूर्ण होते जा रहे हैं
रोचक हिस्सा shader compiler पर केंद्रित है, और 3D API बस shader चलाने और data पहुँचाने की भूमिका तक सीमित रह जाती है
लोग जब इंजन कहते हैं, तो अक्सर asset pipeline और editor को भी उसमें शामिल मान लेते हैं
आज का इंजन सिर्फ main loop + 3D API functions नहीं है
Unity जैसे इंजन का उपयोग करते हुए केवल rendering code लिखने वाले developer बहुत कम हैं
हाँ, Unity/Unreal इस्तेमाल करने का मतलब यह नहीं कि आपको asset tools से पूरी तरह कभी पाला ही नहीं पड़ेगा
हाल में sequel के लिए इंजन फिर से बनाते समय मैं इस बात से पूरी तरह सहमत हुआ
जैसा कि मैंने अपने postmortem में लिखा, ज़्यादातर लोग इंजन कहने पर उस code के बारे में सोचते हैं जो game executable में शामिल होता है, लेकिन व्यवहार में level editor, content pipeline, debugging/profiling, और development workflow जैसे ऐसे code का हिस्सा ज़्यादा बड़ा होता है जो game के साथ ship नहीं होता
tool development, engine development की तुलना में ज़्यादा उबाऊ और थकाऊ काम है
इसी वजह से custom engine पर आधारित कई game development बीच में रुक जाते हैं
postmortem: https://ruoyusun.com/2025/04/18/game-sequel-lessons.html
editor को शुरू से बनाना बहुत बड़ा काम है
जहाँ संभव हो, मौजूदा editor का उपयोग करें
उदाहरण के लिए TrenchBroom (Quake editor) + func_godot का संयोजन, और 2D में Tiled
game data management के लिए CastleDB भी था, लेकिन अब वह Hide (एक full-fledged 3D editor) के साथ integrated है
tools बनाने के बाद game design करना और content बनाना भी एक बड़ा चरण होता है
कुछ साल पहले मैंने SDL2 और थोड़े से C++ से एक साधारण "sprite" class बनाई और उसमें collision जैसी बुनियादी सुविधाएँ जोड़ीं
अगर मैं उसे इंजन कहूँ, तो वह ज़्यादा से ज़्यादा एक electric bicycle assist जैसा था
अक्सर ऐसा होता है कि "इंजन" ही project/game को lead करने लगता है
बहुत बार game को इंजन के हिसाब से ढालना पड़ता है, इसलिए मैं हमेशा Unity जैसे बड़े इंजन से बचता हूँ
आख़िर में ये इंजन लगभग एक जैसे game structure ही बनवाते हैं; बस assets अलग होते हैं
मेरे हिसाब से इंजन सीखने में समय बर्बाद करने से बेहतर है SDL के साथ कम learning curve से शुरुआत करना, और SDL को game के बाहर दूसरे cross-platform project में भी इस्तेमाल किया जा सकता है
मेरा game: https://store.steampowered.com/app/2318420/Glypha_Vintage/
लोग कहते हैं कि अपना इंजन बनाने में बहुत समय लगता है, लेकिन यह भी पूछना चाहिए कि Unreal या Unity को उस स्तर तक सही से सीखने में कितना समय लगेगा जहाँ आप किसी idea को सीधे game में बदल सकें
आख़िरकार जब मेरा इंजन तैयार हो जाता है, तो मेरे पास उसी स्तर की expertise सीधे मौजूद होती है, इसलिए लंबी अवधि में समय बचता है
जितना अधिक engineering अनुभव बढ़ता है, उतना ही समय के हिसाब से खुद बनाना फ़ायदेमंद हो जाता है
जितना game अनोखा या niche होगा, उतना ही खुद बनाना उचित होगा
Unreal के जटिल UI में महीनों भटकने के बाद यह समझना कि जो आप चाहते थे वह general-purpose इंजन में लगभग संभव ही नहीं है, बहुत अलाभकारी अनुभव है
वहीं अगर आप एक ultra-realistic open-world RPG बना रहे हैं, तो खुद सब बनाना अच्छा विकल्प नहीं है
custom engine की सीमाएँ उल्टा creativity को बढ़ावा देती हैं, और भले result top-tier न हो, game ज़्यादा मौलिक बन सकता है
मैंने खुद इंजन बनाया है
शुरुआत में बहुत सारी trial-and-error और dead end के बीच लगभग 1 साल लगा
3D rendering, adaptive UI, skeletal animation, save file, smart object, pathfinding, scripting, audio, physics आदि — game में दिखने वाले लगभग सभी subsystem लागू किए
खास तौर पर rewind feature (Braid के system जैसा) भी खुद implement किया
ऐसी सुविधा के लिए इंजन के सभी subsystem (script, physics आदि) का support चाहिए होता है
मुझे अपने इंजन के हर हिस्से की जानकारी है, इसलिए नई सुविधाएँ जोड़ने में बहुत स्वतंत्रता मिलती है
लेकिन 1 साल के development के बाद धीरे-धीरे burnout आने लगा और motivation खत्म हो गया
Unreal के बारे में नहीं कह सकता, लेकिन Unity में direct coding की तुलना में 10 गुना से भी तेज़ development हो सकता है
physics feature 1 मिनट में जोड़ा जा सकता है, जबकि अपने इंजन में केवल external library integrate करने में ही 1-2 दिन लग सकते हैं
Unreal user Noel द्वारा दिखाई गई internal visualization सुविधाएँ Unity में built-in हैं
bounding box manipulation जैसी editing भी default में मिलती है
अगर इंजन का base behavior पर्याप्त न हो, तो ImGui या Yoga आधारित CSS engine से इसे आसानी से extend किया जा सकता है
advanced particle editor, complexity कम किए गए shader, modular data streaming जैसी अनेक सुविधाएँ मिलती हैं
सिद्धांत में सब कुछ खुद बनाना अच्छा लगता है, लेकिन अंत में समय की वजह से completion को प्राथमिकता देनी पड़ती है
Unreal या Unity सीखकर game idea को तुरंत implement करने में लगने वाला समय, और अपना इंजन बनाने में लगने वाला समय — ये दोनों अलग सवाल हैं
थोड़ा सा idea मिलते ही कुछ घंटों में playable prototype बनाया जा सकता है
Unity में शुरुआती दौर में बस programming काफ़ी है, और Unreal में सिर्फ Blueprint से भी लगभग release के क़रीब तक पहुँचा जा सकता है
10 मिनट में Super Hexagon style game prototype बनाने वाला यह वीडियो देखें: https://www.youtube.com/watch?app=desktop&v=p8MzsDBI5EI
Unity की truly unique चीज़ शायद prefab है; बाकी अधिकतर concepts सामान्य game development के हैं
अगर आप Unreal developer हैं, तो Unity में भी 1 घंटे के भीतर ऐसा ही prototype बना सकते हैं
“इंजन पूरा हो जाने के बाद” वाली धारणा खुद अवास्तविक हो सकती है
GameObject.Instantiateजैसी सरल क्रिया भी इंजन में खुद लागू करनी हो तो बहुत बड़े resource लगते हैं2D/3D physics, shader, platform support जैसी जटिलताओं को भी ध्यान में रखना चाहिए
अगर लक्ष्य इंजन है, तो इंजन बनाइए; अगर लक्ष्य game है, तो game बनाइए
अगर आपके पास गेम डेवलपमेंट का इतना ज्ञान है कि आप गेम इंजन बना सकते हैं
तो Unreal या Unity सीखकर prototype बनाने में एक दिन काफ़ी है
पूर्ण mastery में समय लग सकता है, लेकिन मनचाहा game prototype बनाने का समय उससे तुलना योग्य नहीं है
"सब कुछ करने वाले" बड़े इंजन के बिना भी game बनाना आसान, ज़्यादा मज़ेदार, और कभी-कभी ज़्यादा efficient होता है
लेकिन जब इंजन की किसी खास सुविधा (जैसे Unreal का inverse kinematics, animation blending) में गहराई से जाना पड़ता है, तब लगता है, "अच्छा हुआ यह 2-3 हफ्ते खुद बनाकर नहीं झेलना पड़ा"
minimalism या bloat से बचाव महत्वपूर्ण हैं, लेकिन इन इंजनों की लोकप्रियता का कारण यही है कि ये भारी काम अपने ऊपर ले लेते हैं
पहले मैं भी ऐसा ही करता था
अपना पहला 3D game बनाते समय input, object management, culling, model loading, math library, graphics, normal map, SSAA — सब कुछ implement करता रहा, और आख़िर में game completion 0% रही
फिर भी hobby 2D project में आज भी browser canvas के साथ dependency-free development करता हूँ
असल में browser ही इंजन की भूमिका निभाता है
“अच्छा हुआ खुद नहीं बनाया” वाली बात पर
अगर आप long-term indie developer career के नज़रिए से देखें, तो कुछ हफ्ते ज़्यादा लगने पर भी विषय की गहरी समझ + 100% source code ownership और reuse value अधिक महत्वपूर्ण है
मेरी graduation thesis, NeXTSTEP/Objective-C आधारित particle engine को Windows 95/Visual C++ में port करने पर थी (OpenGL आधारित, marching cubes sample सहित)
ऐसी चीज़ें आजकल के इंजन में बस एक लाइन की feature का छोटा हिस्सा भर हैं
इंजन उपयोग करने से project बहुत तेज़ आगे बढ़ता है, और infrastructure बनाने में समय बर्बाद नहीं करना पड़ता
पहिया दोबारा बनाना ज़्यादातर लोगों के लिए बहुत मज़ेदार काम नहीं है
inverse kinematics या animation blending जैसी सुविधाएँ
अगर game का core हिस्सा हैं, तो उन्हें implement करना सार्थक है; नहीं तो वे अनावश्यक technical trap हैं
मैं Lua & Love2D के साथ अपने तरीके से game बनाता हूँ
खुद पर constraints लगाना ही मज़े का मुख्य हिस्सा है
अगर development मज़ेदार नहीं रह जाए, तो यह संकेत है कि कुछ गड़बड़ है, और बेहतर तरीका खोजना चाहिए
मेरा game YOYOZO सिर्फ 39KB का है, लेकिन Ars Technica की 2023 की best games list में बड़े titles के साथ शामिल हुआ था
https://news.ycombinator.com/item?id=38372936
Playdate खरीदे कई साल हो गए थे, और अब जाकर उसके SDK के साथ खेलना शुरू किया है; Lua भी पहली बार सीख रहा हूँ
मजबूत typing और language safety की इच्छा ज़रूर है, लेकिन यह अपने संदर्भ में पर्याप्त है
अब तक मैंने बस एक छोटा technical demo बनाया है, जिसमें text crank के अनुसार fake 3D space में घूमता है
https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a
इस project पर काम करते हुए मुझे एहसास हुआ कि पुराने CRUD/webapp करियर के चलते मैं trig का लगभग सब कुछ भूल चुका हूँ
Playdate development की सबसे बड़ी खूबी यह आज़ादी है कि canvas fixed है, इसलिए pixel position एक बार तय कर दो तो हर device पर वैसा ही काम करता है
अपने पिछले development career में सिर्फ responsive UI बनाते रहने के बाद यह अनुभव बहुत ताज़गीभरा लगा
जब भी मैं किसी game engine (Godot, Unity, Unreal आदि) से कुछ बनाने की कोशिश करता हूँ, अंत में इंजन से ही जूझता रह जाता हूँ
आख़िरकार ऐसा लगता है जैसे तयशुदा game format पर बस assets चढ़ा रहा हूँ, और मनचाहा game बनाना मुश्किल हो जाता है
web development से तुलना करें तो यह WordPress जैसे ready-made solution जैसा है
जब default structure आपकी मंशा से मेल न खाए, तो बहुत भारी hacking और workaround करने पड़ते हैं
इसमें "game template" और आग में घी डालते हैं
ऐसे template खरीदे जा सकते हैं जो सिर्फ title screen और model बदलकर किसी तैयार game जैसा रूप दे देते हैं
Steam पर आने वाले नए games में लगभग आधे Unity/Unreal template games हैं, जिनमें बस skin थोड़ा बदला गया है
कुछ उदाहरण:
https://assetstore.unity.com/packages/templates/…
https://store.steampowered.com/app/2488370/Cash_Cleaner_Simulator/
https://store.steampowered.com/app/2073910/A_Webbing_Journey/
https://store.steampowered.com/app/3498270/Better_Mart/
https://store.steampowered.com/app/2625420/Drive_Beyond_Horizons/
https://store.steampowered.com/app/3163790/Toy_Shop_Simulator/
https://store.steampowered.com/app/3023600/Horse_Farm_Simulator/
https://store.steampowered.com/app/3124550/Liquor_Store_Simulator/
Google Play पर सभी game एक जैसे लगते हैं, और loading लंबी, rendering issues, text टूटना, audio bugs जैसी Unity-विशिष्ट समस्याएँ दिखती हैं
mobile ads वाले "idle RPG" game के लिए शायद यह चल जाए, लेकिन VR में Unity का उपयोग करना मुझे सच में समझ नहीं आता
Meta Quest Store की performance ज़रूरतें पूरी करने के लिए Unity engine के बड़े हिस्से को बदलना पड़ता है
performance मिलाना मुश्किल है, और काम करने का तरीका भी पुराना लगता है
अगर आप high-quality software बनाना चाहते हैं, तो ऐसे इंजन से शुरुआत करना मुश्किल है जिस पर भरोसा न किया जा सके
लेखक (Noel) ने Celeste नाम का game बनाया है, जिसकी 30 लाख से अधिक copies बिकी हैं
https://en.wikipedia.org/wiki/Celeste_(video_game)
मैं भी काफ़ी हद तक सहमत हूँ, और code-first C# game framework बना रहा हूँ (XNA/Monogame का spiritual successor, SDL की जगह Sokol का उपयोग)
https://zinc.graphics/
modern C# की ताकतें: cross-platform, NativeAOT compilation, native hot reloading, reflection आदि
मैंने personal तौर पर source generators भी जोड़े हैं
पुरानी नकारात्मक छवि अब भी है, लेकिन पिछले 5 साल में CoreCLR और language evolution वाकई शानदार रहे हैं
मुझे बस एक चीज़ चाहिए: Union Types, और उसका proposal अभी मौजूद है, इसलिए उम्मीद है कि अगले साल जुड़ जाएगा
https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md
मैंने C# सिर्फ Win32 या Unity में इस्तेमाल किया है, और C/C++ की low-level engine जानकारी तो है, लेकिन मुझे लगता था कि game console जैसे cross-platform target पर C# संभव नहीं है
अब समझ आया कि मेरी सोच ग़लत थी
किसी भी software में मैं शुरुआत शून्य से करना पसंद करता हूँ
बड़े project का अनुभव रखने वालों को यह धीमा लग सकता है, लेकिन startup चरण में यह उल्टा तेज़ हो सकता है
केवल न्यूनतम चीज़ें implement करें, और जैसे-जैसे abstraction बनती है, नई functionality जोड़ना तेज़ होता जाता है
enterprise-grade बड़े software और मेरे अपने लिखे mini engine की productivity पूरी तरह अलग है
अपने लिखे code में cut करना, refactor करना बहुत आसान होता है, इसलिए गति भी अधिक होती है
इसी कारण मैं microservices और छोटी teams को पसंद करता हूँ
खुद बनाते समय trial-and-error और टूटे हुए landmine जैसे चरणों से गुज़रना ही पड़ता है, और language या platform की असली प्रकृति समझने में भी सालों लगते हैं
लेकिन वही प्रक्रिया अंत में developer की असली ताकत बन जाती है
इंजन के बजाय, MonoGame स्तर का framework इस्तेमाल करना कैसा रहेगा, यह जानने की जिज्ञासा है~
"उस प्रक्रिया से गुज़रना ही आखिरकार डेवलपर की असली क्षमता बनकर रह जाता है" — मैं इससे पूरी तरह सहमत हूँ