मैं C में गेम क्यों बनाता हूँ (हाँ, C में)

 (jonathanwhiting.com)
3 पॉइंट द्वारा GN⁺ 2026-02-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • मैं अपने सभी व्यक्तिगत प्रोजेक्ट के गेम 'pure C' में विकसित करता हूँ, और आज के समय में यह एक दुर्लभ विकल्प है
  • भाषा चुनने के मुख्य मानदंड विश्वसनीयता, पोर्टेबिलिटी और दीर्घकालिक स्थायित्व हैं, ताकि किसी खास OS या प्लेटफ़ॉर्म पर निर्भर न रहना पड़े
  • मैं सरलता और तेज़ compile speed, साथ ही सख्त type checking और मजबूत warning system को महत्व देता हूँ
  • C++·C#·Java·Go·Haxe जैसी वैकल्पिक भाषाओं पर विचार किया, लेकिन complexity, GC, OOP की अनिवार्यता जैसी वजहों से उन्हें उपयुक्त नहीं पाया
  • C खतरनाक है, लेकिन सरल और तेज़ भी, और व्यापक platform support तथा मजबूत library ecosystem की वजह से अब भी सबसे अच्छा विकल्प है

भाषा चुनने के मानदंड

  • सबसे ज़रूरी शर्त विश्वसनीयता और स्थिरता है, ताकि उन bug पर समय बर्बाद न करना पड़े जिन्हें मैंने खुद नहीं बनाया
    • पहले Flash-आधारित गेम बनाए थे, लेकिन Flash के पतन के बाद नए प्लेटफ़ॉर्म पर port करने के बजाय नए गेम बनाने पर ध्यान देना चाहता हूँ
    • किसी खास OS पर निर्भर हुए बिना, और console development की संभावना खुली रखने के लिए portability और general-purpose library support को महत्व देता हूँ
  • वांछनीय शर्तों में सरल syntax और आसानी से याद रहने वाली संरचना शामिल हैं
    • मैं लगातार जटिल API या भाषा सुविधाएँ खोजते रहने की प्रक्रिया से बचना चाहता हूँ
  • सख्त type checking, मजबूत warnings और static analysis के ज़रिए bug कम करना चाहता हूँ, और अच्छे debugger तथा dynamic analysis tools से समस्याएँ आसानी से ढूँढना चाहता हूँ
  • मैं compile speed को बहुत महत्वपूर्ण मानता हूँ
    • लंबे इंतज़ार से फ़ोकस टूटता है और productivity घटती है
  • मैं object-oriented programming (OOP) को लेकर सशंकित हूँ, और data व code को अलग रखकर परिस्थिति के अनुसार संभालने वाले तरीके को पसंद करता हूँ

प्रमुख वैकल्पिक भाषाओं का आकलन

  • C++
    • गेम डेवलपमेंट में अब भी standard है, लेकिन complexity और धीमी compile speed की वजह से संतोषजनक नहीं लगा
    • यह उच्च performance और कई features देता है, लेकिन इसमें बहुत-सी ऐसी चीज़ें हैं जिनकी मुझे ज़रूरत नहीं, और complexity की लागत बहुत अधिक है
  • C# और Java
    • ये शब्दाडंबरपूर्ण और जटिल हैं, और OOP-केंद्रित मजबूत संरचना के कारण लचीलापन कम है
    • high-level language होने के कारण ये complexity को छिपाते हैं, लेकिन मूल समस्याओं को रोकते नहीं
  • Go
    • इसे C की आधुनिक पुनर्व्याख्या के रूप में सकारात्मक रूप से देखता हूँ, लेकिन stop-the-world garbage collection गेम डेवलपमेंट के लिए उपयुक्त नहीं है
    • गेम के लिए libraries की कमी है और दीर्घकालिक स्थिरता को लेकर भी चिंता है
  • JavaScript
    • वेब डेवलपमेंट वातावरण के तेज़ बदलाव और Flash के अंत की वजह से यह अस्थिर महसूस होती है
    • ढीले syntax के कारण इसे बड़े पैमाने के software लिखने के लिए उपयुक्त नहीं मानता
  • Haxe
    • वेब डेवलपमेंट के लिए इसे संभावनाशील मानता हूँ, लेकिन तुलनात्मक रूप से नई भाषा होने के कारण इसकी स्थिरता को लेकर चिंता है
  • अपनी खुद की भाषा बनाना
    • यह विचार आकर्षक है, लेकिन मौजूदा libraries छोड़ने और compatibility बनाए रखने के बोझ की वजह से इसे व्यावहारिक नहीं मानता

C चुनने के कारण

  • यह खतरनाक लेकिन भरोसेमंद भाषा है; इसकी सरल संरचना के कारण सावधानी से इस्तेमाल करने पर यह स्थिर रहती है
    • इसे “तेज़ धार वाले चाकू” से तुलना करते हुए कहा गया है कि इसे संभालना कठिन है, लेकिन महारत होने पर यह बेहद शक्तिशाली औज़ार बन जाती है
  • compile speed बहुत तेज़ है, और यह लगभग हर प्लेटफ़ॉर्म पर चल सकती है
    • porting की प्रक्रिया भी अपेक्षाकृत सरल है, और लंबे समय में भी इसकी स्थिरता की संभावना अधिक है
  • libraries और tooling support मजबूत हैं और लगातार बनाए रखे जा रहे हैं
  • व्यक्तिगत रूप से, मुझे पहले से बहुत-सा 'pure C' code लिखने का अनुभव है, इसलिए यह भाषा परिचित है
  • मैं दूसरों को C इस्तेमाल करने की सलाह नहीं देता; यह मेरी व्यक्तिगत पसंद और काम करने के तरीके के लिए अनुकूलित विकल्प है

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

1 टिप्पणियां

 
GN⁺ 2026-02-09
Hacker News की राय

  • मैं ज़्यादातर C स्टाइल में कोड लिखता हूँ, लेकिन ज़रूरत पड़ने पर ही C++ फीचर इस्तेमाल करता हूँ
    इसलिए ऊपर-ऊपर से देखें तो यह कभी-कभी Rust कोड जैसा भी लगता है
    जो लोग कहते हैं कि वे गेम C में लिखते हैं, वे C++ फीचर्स से नफ़रत करते हुए भी आखिर में virtual interface खुद लागू कर लेते हैं या बहुत बड़ा switch स्टेटमेंट बना देते हैं और वही काम करते हैं
    भाषा में मौजूद फीचर का इस्तेमाल न करें तो बात खत्म, लेकिन उसके अस्तित्व पर शिकायत करना मुझे अर्थहीन लगता है
    C++ में templates का ज़्यादा दुरुपयोग न करें तो compile धीमा नहीं होता

    • अकेले डेवलपमेंट में ऐसा हो सकता है, लेकिन टीम स्तर पर लंबे समय तक maintain होने वाले प्रोजेक्ट्स में स्थिति अलग होती है
      समय के साथ टीम सदस्य बदलते हैं, लीड बदलते हैं, तो इस्तेमाल होने वाले फीचर्स का set धीरे-धीरे बढ़ता जाता है
      एक बार बढ़े हुए फीचर्स को फिर कम करना बहुत मुश्किल होता है
      और कभी-कभी आपको ऐसी library भी इस्तेमाल करनी पड़ती है जो वही फीचर्स इस्तेमाल करती हो जिन्हें आप नहीं चाहते
      उदाहरण के लिए, मुझे implicit calls (destructor, operator overloading वगैरह) पसंद नहीं हैं, लेकिन अगर library उनका इस्तेमाल करती है तो आखिर में मुझे भी उसी के साथ चलना पड़ता है
    • कम से कम switch स्टेटमेंट पढ़ा तो जा सकता है
      C++ की सबसे बुरी बातों में से एक यह है कि अपने-आप बनने वाला छिपा हुआ कोड बहुत ज़्यादा होता है
    • C++ का dynamic dispatch हर type के साथ vtable जोड़ने के तरीके पर आधारित है
      भले ही कोड का ज़्यादातर हिस्सा concrete types (Goose, Duck आदि) से काम कर रहा हो, फिर भी हर object अपने साथ vtable pointer लेकर चलता है
      दूसरी ओर Rust सिर्फ़ वहीं vtable इस्तेमाल करता है जहाँ उसकी ज़रूरत हो, इसलिए memory बचती है
      C प्रोग्रामर ज़रूरत की चीज़ें ही खुद implement करते हैं, इसलिए वे भाषा द्वारा थोपे गए ढाँचे में कम बंधते हैं
    • C++ templates का दुरुपयोग न भी करें तो भी यह धीमा है
      सिर्फ़ <vector> include करने पर भी दसियों हज़ार लाइनों का कोड शामिल हो जाता है
      इसलिए अगर standard library न इस्तेमाल करें तो “फिर से पहिया क्यों बना रहे हो” वाली बहस शुरू हो जाती है
      ऐसी बहस बार-बार हो तो बस C पर लौट जाना कहीं ज़्यादा आसान लगता है
      मैंने भी लगभग 2017 में C पर स्विच किया था, और आज भी जब C++ libraries इस्तेमाल करता हूँ तो थकान महसूस होती है
      अपवाद के तौर पर Dear ImGui ठीक है, लेकिन उसमें भी मैं C bindings को प्राथमिकता देता हूँ
    • मैंने सचमुच C++ फाइल लिखी है जिसमें C++ का एक भी फीचर इस्तेमाल नहीं किया
      extension को .c में बदलते ही compile time आधा हो गया

  • मुझे C का रफ और सीधा-सादा स्वभाव पसंद है, लेकिन preprocessor पसंद नहीं
    इसलिए Zig सचमुच किसी वरदान जैसा लगता है — C से सरल, और साथ ही कहीं ज़्यादा सटीक language design के साथ
    उदाहरण के लिए Zig single pointer और array pointer में फर्क करता है
    आप C libraries को import करके उन्हें इस्तेमाल में आसान बना सकते हैं, और यह गेम डेवलपमेंट में बहुत उपयोगी है
    ज़्यादातर C++ libraries साथ में C headers भी देती हैं
    zig-gamedev में ऐसी बहुत-सी Zig में ढली हुई C libraries हैं
    preprocessor की जगह Zig का comptime फीचर कहीं बेहतर है, और यह बस “compile time पर चलने वाला Zig code” है

    • लेकिन हक़ीक़त में C++ libraries में से C headers export करने वाली बहुत कम हैं

  • मैं भी लेखक की सोच से सहमत हूँ
    किसी भाषा को पसंद करने की सबसे बड़ी वजह सरलता होती है
    इसलिए मुझे C, Go, Odin, Zig जैसी भाषाएँ पसंद हैं
    लेकिन ज़रूरी जटिलता को खूबसूरती से संभालने वाली भाषाएँ भी महत्वपूर्ण हैं
    memory safety, concurrency और functional patterns की ज़रूरत वाले network code में Rust स्वाभाविक लगता है
    वहीं indie games जैसे सरल और तेज़ कोड के लिए C या Odin बेहतर बैठते हैं
    Odin में Go की सरलता और C की performance का मिश्रण महसूस होता है, इसलिए मैं उसे सुझाता हूँ
    Raylib के साथ गेम बनाना भी आसान है

    • दिलचस्प बात यह है कि मैं Zig को अक्सर Go और C के बीच की जगह के रूप में समझाता हूँ
      मुझे जिज्ञासा है कि क्या आपको लगता है कि Odin, Zig से ज़्यादा उस जगह पर फिट बैठता है
    • संदर्भ के लिए, भाषा का नाम Go है, golang सिर्फ़ domain name है

  • मूल लेख में कहा गया था कि Go में game libraries का समर्थन कमज़ोर है, लेकिन वह शायद लगभग 2015 का लेख लगता है
    अब स्थिति बदल चुकी हो सकती है

    • Wayback Machine पर जनवरी 2016 का snapshot है
      वहाँ उस समय बनाए गए गेम्स के screenshots भी देखे जा सकते हैं
      उदाहरण के लिए Knossu का 3D स्टाइल काफ़ी अनोखा है

  • 2026 में C में गेम बनाना थोड़ा पागलपन लग सकता है, लेकिन मैं भी ऐसा करता हूँ
    उदाहरण के लिए Chrysalis को मैंने C में डेवलप किया था (GLFW3, FMOD इस्तेमाल करके)

    • मैं पिछले 2 साल से Jedi Academy codebase पर काम कर रहा हूँ (C & C++)
      यह idTech3 पर आधारित है, और इसका combat system इतना सटीक है कि छोटा-सा बदलाव भी पूरा balance बिगाड़ देता है
      यहाँ तक कि सिर्फ़ i++ जोड़ने से भी timing बदल जाती है
      इसलिए हम अब भी 22 साल पुराने compiler का ही इस्तेमाल कर रहे हैं
      आधुनिक forks मौजूद हैं, लेकिन उनमें original feel खो गई है
      idTech3 सचमुच C का निचोड़ दिखाने वाला engine है

  • हज़ारों गेम C में लिखे गए हैं, और OpenGL, Vulkan, DX जैसी graphics APIs भी पूरी तरह C आधारित हैं
    इसलिए इसमें कुछ भी अजीब नहीं है
    ज़्यादातर game engines भी C/C++ में लिखे जाते हैं

    • Khronos APIs C हैं, DirectX C++ आधारित COM/WinRT है, और Metal Objective-C और C++ का मिश्रण है
      consoles हर पीढ़ी में अलग रहे हैं
    • SDL3 भी C में लिखा गया है, और Box2D का नया version भी फिर से C में लिखा गया है
    • DirectX C++ है, और ज़्यादातर game engines भी C++ हैं
      Linux programming के विपरीत, game development 30 साल से ज़्यादा समय तक C++ केंद्रित रहा है

  • मूल रूप से मैं C से प्यार करने वाला इंसान हूँ
    दशकों तक इसे अच्छे से इस्तेमाल किया है, लेकिन टीम के साथ C code manage करने पर दर्द बढ़ जाता है
    और आधुनिक भाषाओं की तुलना में development speed भी धीमी है
    फिर भी इसकी सरलता का आकर्षण अब भी बना हुआ है

    • मैं जानना चाहूँगा कि टीम वर्क में C codebase ज़्यादा दर्दनाक क्यों हो जाता है
      मेरे अनुभव में C, C++ से कम तकलीफ़देह था
    • “कम कहो, ज़्यादा मतलब रखो” — यानी संक्षिप्तता ही असली बात है
    • Linux kernel में सिर्फ़ 2025 में ही 2,134 developers ने योगदान दिया था
      यह तथ्य C की सहयोग संबंधी सीमाओं वाले तर्क को कमज़ोर करता है

  • “कोई भी C में गेम नहीं बनाता” कहना बढ़ा-चढ़ाकर कहना है
    आज यह mainstream नहीं है, लेकिन अब भी बहुत लोग C में गेम बनाते हैं

    • “कोई नहीं” या “सब” जैसे शब्द आम तौर पर पूर्ण अर्थ में नहीं बोले जाते
      आप सिर्फ़ अपवाद हैं, और यह कथन फिर भी सांख्यिकीय रूप से सही हो सकता है

  • मुझे C पसंद है
    memory management पर पूरा नियंत्रण मिलता है, और behavior अनुमानित रहता है
    MISRA rules जैसी pre-allocation माँगने वाली परिस्थितियों में यह खास तौर पर उपयोगी है
    hardware level exceptions या errors को सीधे संभालने में भी यह अच्छा है
    unit tests लिखना भी आसान है

  • C में प्रवेश बाधा कम है, लेकिन memory management की समझ अनिवार्य है
    एक Java developer होने के नाते, जब मुझे सिर्फ़ .h और .so देकर जल्दी से एक connector बनाना था, तब मैंने C++ के बजाय C चुना
    अगर C एक तेज़ धार वाला चाकू है, तो C++ घूमते हुए चाकुओं का खंभा है — ज़रा-सी असावधानी में चोट लगती है
    लेकिन string handling C में इतना दर्दनाक है कि मन करता है C++ की string system उधार ले लूँ

    • C++ की अच्छी बात यह है कि जिन फीचर्स की ज़रूरत नहीं, उन्हें इस्तेमाल न करना भी संभव है