Oleg Sidorkin द्वारा, Cinevva के CTO

नौ साल बाद Bungie ने Destiny 2 का active development बंद कर दिया है, आगे छँटनी होनी है, और अपने लोगों को Marathon पर लगा दिया है, एक ऐसा game जिसने अपने पहले ही महीने में आधे से ज़्यादा concurrent players खो दिए। कुछ हफ़्ते पहले OpenAI ने Sora को बंद कर दिया, करीब बीस लाख डॉलर की lifetime revenue के मुकाबले रोज़ाना लगभग दस लाख डॉलर फूँकने के बाद। पूरी बहार के मौसम में एक studio के बाद दूसरे studio ने staff में कटौती की। इन्हें अलग-अलग खानों में डाल देना आसान है, live service की थकान, AI का शोर, एक सुस्त economy। पर ये तीन अलग-अलग भेस में एक ही नाकामी हैं।

तीन ढहाव, एक ही आकार

हर कहानी का ढाँचा एक जैसा है। एक बेहद महँगी चीज़ बहुत ऊँचे fixed costs ढोती है। audience बदल जाती है। cost का ढाँचा उसके साथ नहीं बदल पाता। Destiny 2 को बस अपनी जगह टिके रहने भर के लिए सैकड़ों लोगों की ज़रूरत थी, जो हमेशा content भेजते रहें। Sora की लागत हर बने video के साथ बढ़ती थी, इसलिए लोकप्रियता ने रिसाव को और बढ़ाया, घटाया नहीं। एक 300 लोगों का studio, जिसके पास production में एक flagship है, ऐसा payroll चलाता है जिसे इससे कोई फ़र्क नहीं पड़ता कि flagship अच्छा चल रहा है या नहीं। जब revenue हिलती है और costs उसके पीछे नहीं चल पातीं, तो बचा हुआ एकमात्र लीवर है लोगों की कटौती। इसीलिए इनमें से हर एक का अंत छँटनी में होता है।

समस्या कभी product थी ही नहीं

Bungie की गलती यह नहीं थी कि Destiny 2 नाकाम रहा। यह नौ साल चला और एक समर्पित audience कमाई। गलती यह थी कि इसका इकलौता follow-up एक और nine-figure live service game था, इसलिए जब Marathon लड़खड़ाया तो वापस लौटने के लिए कोई छोटी चीज़ नहीं थी। Sora कोई बुरा demo नहीं था। यह सचमुच एक प्रभावशाली model था, जो एक ऐसे economic engine से बंधा था जो अपनी ही कामयाबी को सज़ा देता था। दोनों मामलों में जो चीज़ उन्होंने भेजी, वह काम कर रही थी। जो काम नहीं कर रहा था वह था उसके पीछे लगे दांव का आकार। जो studio अपना सब कुछ एक ही विशाल title में लगा देता है, उसके पास कोई shock absorber नहीं होता। पहली खराब तिमाही ही आखिरी भी होती है।

इकलौता असली बचाव है एक सस्ती चूक

यहाँ वह हिस्सा है जिसे headlines छोड़ देती हैं। जो studios और tools मंदी में टिके रहते हैं, वे ऐसे नहीं हैं जो ज़्यादा बार जीतने वाले चुन लेते हों। कोई भी भरोसे से जीतने वाले नहीं चुन पाता। ये वे हैं जहाँ एक चूक company को खत्म नहीं करती। अगर किसी game में एक छोटी team के कुछ हफ़्ते लगें, बजाय कुछ सौ लोगों के कुछ साल के, तो एक flop एक मंगलवार है, अंतिम संस्कार नहीं। जिस गणित ने अभी Destiny 2 का development खत्म किया, वह मान कर चलता है कि हर दांव बहुत बड़ा है और इसलिए हर नुकसान घातक है। एक कोशिश की लागत को इतना नीचे गिरा दो कि यह तर्क ही उलट जाए। तब आप ज़्यादातर वक़्त गलत होने की छूट पा लेते हैं, और कभी-कभार सही होने का एकमात्र ईमानदार तरीका यही है।

इसीलिए fixed-cost का जाल structural है, न कि Bungie की समस्या या OpenAI की समस्या। ऐसा कोई भी model जिसे सैकड़ों लोगों की ज़रूरत हो, या जिसका compute revenue से तेज़ रफ़्तार से बढ़ता हो, अपने डिज़ाइन से ही नाज़ुक है। यह तब तक मज़बूत दिखता है जब तक audience हिल नहीं जाती, और audience हमेशा हिलती है।

अगर आप कुछ बना रहे हैं तो इसका क्या मतलब है

भविष्य कम, बड़े games का नहीं है जिन्हें हज़ार लोगों की teams ढोएँ। यह कहीं ज़्यादा games का है जिन्हें छोटी teams और अकेले लोग बनाएँगे, जहाँ कुछ आज़माने की लागत लगभग शून्य है। यह आशावाद नहीं है, economics इसी ओर इशारा कर रही है। जो audience Destiny को छोड़ गई, वह गायब नहीं हुई। वह दर्जनों games में बिखर गई, और जो अगली लहर उसे पकड़ेगी वह किसी भी दशक भर चलने वाले monolith से सस्ती बनेगी, तेज़ भेजी जाएगी और iterate करने में आसान होगी।

यही वह दांव है जो हम Cinevva में बना रहे हैं। ऐसे games जो browser में बनें और खेले जाएँ, जहाँ एक कोशिश की लागत इतनी कम हो कि एक चूक studio को अपने साथ न ले डूबे। जिस economics ने अभी Destiny 2 का development खत्म किया, उसी economics के इर्द-गिर्द रास्ता निकालने के लिए हमने यह platform बनाया है। दिग्गज मुश्किल तरीके से सीख रहे हैं कि shock absorber के बिना scale सिर्फ़ खतरे में पड़ना है। जो लोग इसे सबसे पहले आत्मसात कर लेते हैं, वे मंदी के दौर में कटने के बजाय उसके पार बनाते रहते हैं।

संबंधित:

• Bungie ने Destiny 2 का development खत्म किया — बंदी, छँटनी और Marathon का दांव
• Sora खत्म हो गया — बीस लाख डॉलर की lifetime revenue के मुकाबले रोज़ाना दस लाख डॉलर
• Game industry की छँटनी मार्च 2026 तक जारी — व्यापक संकुचन
• दिग्गजों का मलबा — ढहाव के दूसरी ओर indie का मौका
• Game creators के लिए — खेलने लायक games publish करें, subscription pool, playtime के आधार पर भुगतान

Mariana Muntean, Cinevva की CEO द्वारा

किसी स्टूडियो के एक game को बंद करने की हर कहानी एक त्रासदी की तरह लिखी जाती है, और जो लोग अपनी नौकरी खो रहे हैं उनके लिए यह सच में त्रासदी है। लेकिन इसके नीचे एक दूसरी कहानी छिपी है, जिसका कोई प्रेस रिलीज़ नहीं होता। जब Bungie, Destiny 2 का सक्रिय development बंद करता है, तो वह सिर्फ़ एक टीम की छँटनी नहीं कर रहा होता। वह एक दर्शक-समूह को छोड़ रहा होता है। लाखों players जिन्होंने अपनी शामें एक game के इर्द-गिर्द सजाई थीं, धीरे-धीरे अगले game की तलाश में निकल पड़ते हैं। यह games के लिए नुकसान नहीं है। यह एक पुनर्वितरण है, और छोटी टीमें इसका उससे ज़्यादा हिस्सा पकड़ सकती हैं जितना वे सोचती हैं।

एक सूर्यास्त असल में एक प्रवास है

जब कोई live-service game सिमटने लगता है, तो उसके players games खेलना नहीं छोड़ते। वे वह game छोड़ते हैं। Destiny की community ने दोस्तों के साथ खेलने में दिलचस्पी नहीं खोई। उन्होंने बस एक ख़ास जगह पर खेलते रहने की वजह खो दी। इससे पहले हर बड़े सूर्यास्त के बाद यही हुआ है। दर्शक बिखर जाते हैं, और जो कुछ नया, सामाजिक और जीवंत महसूस होता है उसी की ओर बिखरते हैं। दिग्गजों ने एक दशक उन players को एक ही कमरे में खींचने में लगाया। अब दरवाज़े खुल रहे हैं और players फिर से खुले बाज़ार में हैं।

विस्थापित players सबसे सस्ते दर्शक हैं जिन तक आप कभी पहुँचेंगे

games में सबसे कठिन काम एक game बनाना नहीं है। सबसे कठिन है किसी को उसे आज़माने के लिए तैयार करना। ज़्यादातर छोटे studios के लिए सबसे महँगा खर्च ध्यान है। एक player जो किसी बंद होते live-service game से बाहर आ रहा है, वह कुछ समय के लिए सक्रिय रूप से कुछ नया खोज रहा होता है। उसके पास वह समय है जो वह पहले खर्च करता था, एक दोस्तों का समूह है जो साथ मिलकर एक नया ठिकाना ढूँढ रहा है, और कोई मौजूदा वफ़ादारी नहीं है। यह इस कारोबार में सबसे दुर्लभ मेल है, प्रेरित और मुक्त और समूहों में आता हुआ। आपको उन्हें किसी चीज़ से छुड़ाना नहीं पड़ता। दिग्गज पहले ही उन्हें छोड़ चुका है।

दिग्गज अब क्या नहीं कर सकते

यहाँ असंतुलन है। एक हज़ार लोगों का स्टूडियो बिखरे हुए दर्शकों का पीछा नहीं कर सकता। इसका लागत-ढाँचा, वह फिक्स्ड-कॉस्ट ट्रैप जिसके बारे में हमने लिखा था, तभी काम करता है जब उसे एक बड़ी सफलता मिले। बारह niches के लिए बारह अजीब games उस आकार की payroll नहीं चला सकते। तो ठीक उसी पल जब दर्शक बिखरते हैं, दिग्गज उन्हें सेवा देने में सबसे कम सक्षम होते हैं। यही खाई indie के लिए मौका है। छोटी टीमें वे अजीब, ख़ास, सामाजिक games बना सकती हैं जो किसी टुकड़े का एक टुकड़ा सच में चाहता है, इतनी कम लागत पर कि एक niche दर्शक ही काफ़ी से ज़्यादा हो जाता है।

जब वे उतरें तब वहाँ कैसे रहें

सही समय पर मलबे में मौजूद रहना किस्मत नहीं है, यह स्थिति बनाने का मामला है। इसका मतलब है एक launch पर सब कुछ दाँव पर लगाने के बजाय बार-बार ship करना। इसका मतलब है games को इतना सस्ता बनाना कि जब प्रवास शुरू हो तब आपके पास एक तैयार हो, उसके ख़त्म होने के अठारह महीने बाद नहीं। इसका मतलब है विस्थापित players से वहीं मिलना जहाँ वे पहले से हैं, एक browser tab में, ऐसी चीज़ के साथ जिसे वे एक click में खेल सकें और अपने दोस्तों को साथ ला सकें।

यही हम Cinevva में बना रहे हैं। एक ऐसी जगह जहाँ छोटी टीमें playable games तेज़ी से ship करती हैं, ad बजट के बजाय reels के ज़रिए खोजी जाती हैं, और launch के उछाल के बजाय playtime से कमाती हैं। दिग्गज पूरी इंडस्ट्री को सिखा रहे हैं कि स्केल नाज़ुक होता है। इस सबक का दूसरा पहलू यह है कि उनके दर्शक अब उपलब्ध हैं, और जो लोग उन्हें पकड़ने के लिए तैयार हैं वे वही हैं जिन्हें पहले कभी दर्शकों के विशाल होने की ज़रूरत ही नहीं थी।

संबंधित:

• फिक्स्ड-कॉस्ट ट्रैप — दिग्गज सबसे पहले नाज़ुक क्यों होते हैं
• Bungie ने Destiny 2 का development बंद किया — नौ साल के दर्शक, फिर से बाज़ार में
• Game इंडस्ट्री की छँटनी मार्च 2026 तक जारी — सिकुड़न का पैमाना
• game creators के लिए — reels खोज, subscription pool, playtime भुगतान

Oleg Sidorkin द्वारा, Cinevva के CTO

दो महीने पहले हमने लिखा था कि browser rendering का अब तक का सबसे अच्छा महीना रहा, और हमने मान लिया था कि यह एक उछाल भर है। ऐसा नहीं था। यह एक ट्रेंड की शुरुआत थी, और इस ट्रेंड की एक दिशा है। ब्राउज़र अब वह जगह बनता जा रहा है जहाँ आप एक असली game शिप करते हैं, न कि वह जगह जहाँ आप एक छोटी सी game को port करते हैं।

मार्च के बाद से क्या आया

लिस्ट देखिए। Babylon.js 9 हज़ारों dynamic lights के लिए clustered lighting, volumetric lighting, और पूरा Gaussian splatting overhaul लेकर आया। Three.js r184 ने HTMLTexture जोड़ा, जो live, interactive DOM को एक 3D surface पर texture के रूप में render करता है। PlayCanvas v2.17 ने WebGPU पर GPU-driven Gaussian splatting दिया, जिसमें f16 spherical harmonics और GPU sorting और frustum culling शामिल हैं। Godot 4.7 beta ने wasm64 web export जोड़े जो पुरानी 4 GB मेमोरी सीमा हटाते हैं, साथ में असली HDR output और area lights। Chrome 146 ने एक WebGPU compatibility mode शिप किया जो OpenGL ES 3.1 और Direct3D 11 पर चलता है, और WebGPU खुद W3C Candidate Recommendation तक पहुँच गया। इनमें से कोई एक भी एक उल्लेखनीय तिमाही बना देता। ये सब लगभग आठ हफ्तों में आ गए।

"डेमो के लिए काफी अच्छा" अब "शिप करने के लिए काफी अच्छा" बन गया

जो features आए वे खिलौने नहीं हैं। Clustered lighting वह तरीका है जिससे आप frame rate गिराए बिना एक scene को हज़ारों dynamic lights से रोशन करते हैं। Gaussian splatting वह तरीका है जिससे आप interactive frame rates पर photoreal captured environments को एक game में डालते हैं। GPU-driven sorting और culling एक ऐसे tech demo, जो अटकता है, और एक ऐसी game, जो 60 बनाए रखती है, के बीच का फर्क है। ये वही तकनीकें हैं जिनका इस्तेमाल native engines AAA शिप करने के लिए करते हैं, और अब ये एक tab में चलती हैं। compatibility-mode वाला काम दूसरी दिशा में भी उतना ही मायने रखता है। इसका मतलब है कि WebGPU उस सस्ते और पुराने hardware तक पहुँचता है जो ज़्यादातर players के पास सचमुच होता है, न कि सिर्फ high-end GPU वाली developer machines तक।

हम इस पर खुद, हाथ से, बनाते आ रहे हैं

हम यह किसी press release से पढ़कर नहीं बता रहे। हमने पिछले अरसे में एक open world बनाने में लगाया है जो ब्राउज़र में चलती है, साठ से ज़्यादा spike experiments के दौरान, भद्दे terrain baselines से लेकर GPU marching cubes और streaming LOD तक। हमने इस सफर को एक पूरी सीरीज और methodology पर एक लंबे लेख के रूप में लिखा। ऊपर बताया गया लगभग हर feature किसी ऐसी समस्या से जुड़ता है जिसे हमने मुश्किल तरीके से झेला। जब clustered lighting एक mainstream web engine में आता है, तो वह हमारे अपने code का एक हिस्सा है जिसे हम मिटा सकते हैं।

आपत्ति मर चुकी है, आदत नहीं

"आप एक ब्राउज़र में असली game नहीं बना सकते" यह लंबे समय तक सच था, और यह तब सच होना बंद हुआ जब ज़्यादातर इंडस्ट्री AI की तरफ दूसरी ओर देख रही थी। वह तकनीकी सीमा, जो पहले एक native client और फिर एक web build शायद-कभी-नहीं शिप करने को सही ठहराती थी, हट चुकी है। जो बचा है वह आदत है। Engines, studios, और toolchains अब भी इस मान्यता के इर्द-गिर्द बने हैं कि ब्राउज़र एक कमतर target है।

वही मान्यता मौका है। हमने Cinevva को इस दांव पर बनाया कि ब्राउज़र games शिप करने और खोजने की डिफ़ॉल्ट जगह बन जाएगा, न कि fallback। rendering stack ने अभी-अभी दो महीने इस दांव को सही साबित करने में बिताए हैं। जो studios अपना मानसिक मॉडल पहले अपडेट करते हैं, उन्हें बिना install friction वाला एक distribution surface और एक click दूर बैठा audience मिलता है। जो इंतज़ार करते हैं वे आखिरकार इस पर port करेंगे ही, तब जब बाकी सब पहले से ही वहाँ रह रहे होंगे।

संबंधित:

• Browser rendering का अभी-अभी अब तक का सबसे अच्छा महीना रहा — वह उछाल जिसे हमने एक बार की बात समझा था
• Babylon.js 9 रिलीज़ हुआ — clustered lighting और Gaussian splatting
• Three.js r184 में HTMLTexture आया — live DOM एक 3D surface के रूप में
• PlayCanvas v2.17 में GPU-driven Gaussian splatting जुड़ा — WebGPU पर बड़े पैमाने पर splatting
• Godot 4.7 beta — HDR output, area lights, wasm64 web export
• एक ब्राउज़र में open world बनाने में क्या लगता है — हमारा अपना सफर

Mariana Muntean, Cinevva की CEO द्वारा

GDC के 2026 के State of the Game Industry survey ने दो मिलते-जुलते आँकड़े सुर्खियों में डाल दिए। 52% game कंपनियाँ production में generative AI इस्तेमाल करने की बात कहती हैं और ठीक उसी समय 52% developers कहते हैं कि generative AI इंडस्ट्री पर नकारात्मक असर डाल रहा है। एक ही प्रतिशत, भविष्य पर बिल्कुल उल्टी राय।

इस तालमेल के नीचे एक और बँटवारा छुपा है जिसे कम तवज्जो मिलती है। सिर्फ़ 36% लोगों ने कहा कि वे खुद generative AI इस्तेमाल करते हैं, जबकि कंपनी के स्तर पर इसका अपनाव इससे ऊँचा है। मैनेजमेंट ऐसे tools खरीद रहा है जिन्हें बहुत सारे अलग-अलग developers कभी छूते तक नहीं। यह फ़ासला इस बात का इशारा है कि असली बहस कहाँ चल रही है। यह सिर्फ़ नैतिकता नहीं है। यह इस बारे में है कि pipeline को कौन नियंत्रित करता है और क्या keyboard के सामने बैठा इंसान मानता है कि AI सचमुच उसका काम कर सकता है।

मैन्युअल रहने का आराम

बहुत से developers जो AI से बचते हैं वे भोले नहीं हैं। उनके दिमाग में एक मॉडल चल रहा है जो कुछ ऐसा सुनाई देता है: मेरा काम मुश्किल समस्याओं की एक कड़ी है जो किसी chat prompt में सिमट नहीं जाती। एक अनोखी सोच को modeling के संपर्क में टिकना पड़ता है। एक model को rigging में टिकना पड़ता है। rigging को animation में टिकना पड़ता है। animation को gameplay के अहसास और systems design में टिकना पड़ता है। हर बार जब काम एक से दूसरे के हाथ जाता है, तो स्वाद और बंदिशें मायने रखती हैं। एक LLM जो किसी किरदार के बारे में एक ठीक-ठाक पैराग्राफ़ लिख दे, वह उस mesh जैसी चीज़ नहीं है जो सही ढंग से मुड़ती हो, या उस rig जैसी जिससे animator को झगड़ना न पड़े, या उन mechanics जैसी जो लसलसी के बजाय जानबूझकर बनाई हुई लगें।

यह कहानी आज ज़्यादातर tools के काम करने के तरीके के लिए ग़लत नहीं है। आम models अकेली-अकेली tasks में सबसे मज़बूत हैं। वे एक ही रचनात्मक धागे को कई विषयों के आर-पार थामे रखने में कमज़ोर हैं, जब तक आप टुकड़ों को खुद जोड़ न दें। तो AI पर भरोसा न करके "सुरक्षित" महसूस करना कुछ हद तक तकनीकी है। अगर आपका काम concept art, topology, skin weights, state machines और camera language के बीच का गोंद है, तो यह मानना आसान है कि automation सालों तक उथले हिस्से में ही टिका रहेगा।

Steam और दूसरे खिलाड़ी अब भी लकीरें खींचते हैं

यही सहज सोच distribution की तरफ़ भी दिखती है। Steam generative AI इस्तेमाल करने पर games को आर-पार रोकता नहीं है। पर Valve यह ज़रूर माँगता है कि जब AI से बनी सामग्री players तक पहुँचे तो उसका साफ़ खुलासा हो, और अगर game runtime पर लाइव सामग्री बनाता है तो उसकी और भी ज़्यादा जाँच होती है। Listings को rights और safety के नियमों के सही पक्ष में भी रहना पड़ता है। यह mesh topology की समस्या जैसा नहीं है, पर यह एक और वजह है कि teams AI को जोखिम भरा मानती हैं। एक बड़े PC storefront ने सवाल को "क्या हम इसे बना सकते हैं?" से बदलकर "क्या हम इसे यहाँ बिना label की लड़ाई या review में किसी चौंकाने वाली बात के भेज सकते हैं?" बना दिया।

दूसरे gatekeepers और भी सख़्ती से पेश आए। Games Workshop ने Warhammer properties के आर-पार AI से बनी रचना पर रोक लगा दी। Indie Game Awards ने development में AI इस्तेमाल को लेकर एक बड़ा nomination वापस ले लिया, भले ही fans ने दलील दी कि भेजा गया game साफ़ था। Community moderators AI जैसे दिखने वाले trailer के काम पर इस्तीफ़ा देकर चले गए। Epic के Tim Sweeney और Valve सार्वजनिक रूप से बहस कर चुके हैं कि Steam-जैसे labels मदद करते हैं या नुकसान। बात यह नहीं है कि कौन-सा executive सही है। बात यह है कि distribution और IP के मालिक बँटते जा रहे हैं। एक developer जो पूरी तरह मैन्युअल रहता है वह उस लड़ाई की एक पूरी परत को आसान कर देता है। player build में कोई generative asset न होने का मतलब है खुलासा करने के लिए कम और बचाव करने के लिए कम, जब कोई forum तय कर ले कि आपका key art बनावटी दिखता है।

trust और labeling की परत के बारे में हमने AI controversy, trust, and the post-AI economy में और लिखा है, और Cinevva पर labels को हम कैसे संभालते हैं यह AI-generated content policy में बताया है।

वह सुरक्षा डगमगाती क्यों है

वही survey दिखाता है कि भावना तेज़ी से बदल रही है। AI के इंडस्ट्री पर असर के बारे में शुद्ध सकारात्मक राय गिरी। नकारात्मक राय बढ़ी। छँटनी के आँकड़े और union को मिला समर्थन बताते हैं कि लोग शांत नहीं हैं। तो मनोवैज्ञानिक तस्वीर फिर से बँट जाती है। कुछ developers सुरक्षित महसूस करते हैं क्योंकि पूरा stack अब भी मुश्किल है। दूसरे असुरक्षित महसूस करते हैं क्योंकि studios वैसे भी efficiency खरीद रहे हैं, उनकी सहमति के साथ या उसके बिना।

ये दोनों समूह हमेशा stack की एक ही परत की बात नहीं कर रहे होते। Executives का अक्सर मतलब होता है "क्या हम इस milestone पर कम में ज़्यादा भेज सकते हैं?" Artists और designers का अक्सर मतलब होता है "क्या मेरी ख़ासियत आगे भी रहेगी?" दोनों सवाल असली हैं। पहला आंशिक automation को इनाम देता है। दूसरा हर उस इंसान को सज़ा देता है जिसने मान लिया था कि pipeline का उसका कोना इतना ख़ास है कि उसे छुआ नहीं जा सकता।

हिसाब को सचमुच क्या बदलेगा

अगर इंडस्ट्री एक-एक की generators से जुड़े हुए workflows की ओर बढ़ती है, जहाँ एक concept, एक rig और एक playable loop एक ही context साझा करते हैं, तो "मैं सुरक्षित हूँ क्योंकि यह बहुत custom है" वाली दलील सिकुड़ जाती है। इसलिए नहीं कि स्वाद ख़त्म हो जाता है। बल्कि इसलिए कि steps के बीच के उबाऊ जोड़ आपका आधा कैलेंडर खाना बंद कर देते हैं। शुद्ध मैन्युअल workflows के लिए ख़तरा कोई एक model नहीं है जो सब कुछ करता हो। ख़तरा कम जोड़ हैं।

यही वह दाँव है जिसकी ओर हम Cinevva पर बना रहे हैं। browser में AI-assisted creation, ऐसे tools जो एक-दूसरे को feed करते हैं, और काम-चालू-है से लेकर ऐसी चीज़ तक का रास्ता जिसे players सचमुच चला और खोज सकें। इसलिए नहीं कि executives किसी spreadsheet पर teams को बदल दें। बल्कि इसलिए कि एक छोटा समूह या अकेला dev आइडिया से लेकर भेजे गए game तक की पूरी कड़ी का मालिक बन सके, बिना यह दिखावा किए कि एक prompt किसी lead artist की जगह ले लेता है।

जो 52% AI इस्तेमाल करते हैं और जो 52% डरते हैं कि यह इंडस्ट्री के साथ क्या कर रहा है, दोनों असली संकेतों पर प्रतिक्रिया दे रहे हैं। जो developers आज AI छोड़कर सुरक्षित महसूस करते हैं उनके पास जटिलता को लेकर एक गंभीर दलील है। खुला सवाल यह है कि वह दलील कब तक सच रहती है अगर toolchain हर विषय की सीमा पर टूटना बंद कर दे।

संबंधित:

• GDC 2026 by the numbers — हाज़िरी, engine बाज़ार हिस्सेदारी, और AI की दरार
• Everyone wants to be the AI game engine now — अपनाव के पीछे की platform दौड़
• Open source has an AI pollution problem — सस्ती AI generation का कीमत वाला पहलू
• AI controversy, trust, and the post-AI economy — Steam के आँकड़े, studio की प्रतिक्रियाएँ, और trust
• AI-generated content policy — Cinevva खुलासे और filters को कैसे संभालता है
• Vibe coding is the new game jam — जब प्रयोग सस्ता हो जाता है
• For game creators — playable games प्रकाशित करें, subscription pool, playtime आधारित भुगतान

Oleg Sidorkin द्वारा, Cinevva के CTO

जब गेम इंडस्ट्री ने मार्च का पूरा महीना GDC में AI को लेकर बहस करने में बिता दिया, तब browser rendering stack ने चार हफ़्तों में पाँच साल की प्रगति कर डाली। किसी ने कोई press conference नहीं की। किसी ने कोई hot take पोस्ट नहीं किया। पाँच अलग-अलग चीज़ें हुईं, जिन्होंने मिलकर "browser game" का मतलब ही बदल दिया।

Babylon.js सालों से browser rendering को आगे बढ़ा रहा है। Version 9.0 ने अब तक की सबसे बड़ी छलांग लगाई।

मार्च 2026 में क्या-क्या आया

Babylon.js 9.0 clustered lighting के साथ launch हुआ, यह एक rendering तकनीक है जो performance को बिना नुकसान पहुँचाए एक scene में सैकड़ों dynamic lights संभाल लेती है। अब तक यह एक AAA engine का feature था। इस release में volumetric lighting भी है जिसमें realistic light scattering होती है, stained glass और LED displays जैसे effects के लिए textured area lights हैं, और एक node-based particle editor भी है। यह सब WebGPU और WebGL 2 दोनों पर चलता है।

PlayCanvas v2.17 ने WebGPU पर GPU-driven Gaussian Splatting sorting दिया। Gaussian splatting वह तकनीक है जो photogrammetry captures को real-time 3D scenes में बदल देती है, और दो साल पहले यह सिर्फ़ एक research paper थी। अब यह एक browser engine में चल रही है, और sort pass के लिए GPU acceleration के साथ चल रही है।

Three.js r183 ने अपने PostProcessing module का नाम बदलकर RenderPipeline कर दिया। यह सुनने में एक छोटा सा API change लगता है, पर इस नाम के मायने हैं। "Post processing" वह चीज़ है जिसे आप किसी hobby project पर जोड़ देते हैं। "Render pipeline" production infrastructure है। Three.js टीम यह संकेत दे रही है कि यह library अब गंभीर और structured rendering architectures के लिए तैयार है।

Chrome 146 ने WebGPU Compatibility Mode जोड़ा, जिसका मतलब है कि जो पुराने GPUs पूरे WebGPU feature set को support नहीं करते, वे अब एक कम-क्षमता वाले रास्ते से WebGPU इस्तेमाल कर सकते हैं। WebGPU का install base अभी-अभी बहुत बढ़ गया है।

W3C ने WebGPU को Candidate Recommendation Draft के रूप में प्रकाशित किया। यह इसके एक आधिकारिक web standard बनने की ओर एक औपचारिक कदम है। WebGPU अब experimental नहीं रहा। यह standards track पर है।

यह महीना क्यों अलग है

इनमें से कोई भी एक release अपने आप में ध्यान देने लायक है। पर पाँचों का एक ही महीने में होना एक जुड़ता-बढ़ता असर पैदा करता है।

पाँच साल पहले, "browser game" का मतलब था एक 2D casual game, और अगर आप थोड़े महत्वाकांक्षी हैं तो शायद उसमें कुछ Canvas effects। तीन साल पहले, आप careful optimization के साथ बुनियादी 3D कर सकते थे। एक साल पहले, WebGPU production browsers में आना शुरू हुआ और छत ऊपर उठने लगी।

पर मार्च 2026 वह समय है जब native और browser rendering के बीच का फ़र्क "बड़ा" से "तेज़ी से घटता हुआ" बन गया। Clustered lighting के लिए पहले आपको Unreal या Unity चाहिए था। Gaussian splatting के लिए आपको एक research lab चाहिए था। Production-quality post-processing pipelines के लिए आपको एक custom engine चाहिए था। ये तीनों अब open-source browser engines में आ रही हैं, जिन्हें कोई भी npm install कर सकता है।

Three.js Water Pro, WebGPU पर चलता हुआ। यह एक browser है।

मुझे लगता है आगे क्या होगा

Cinevva में हम शुरुआत से ही browser-first game delivery पर दाँव लगा रहे हैं। हमारी थीसिस हमेशा यही थी कि rendering का फ़र्क घटेगा, क्योंकि web platform native engines से तेज़ी से आगे बढ़ता है। WebGPU में मेरी उम्मीद से ज़्यादा समय लगा, पर यह मिलन अब अपने तय समय पर हो रहा है।

इसका व्यावहारिक असर है distribution। जो game एक browser में चलता है, उसे न किसी download की ज़रूरत है, न install की, न किसी platform approval की प्रक्रिया की। वह एक URL से load होता है। यह हमेशा से browser का फ़ायदा रहा है, पर इसके मायने तभी हैं जब rendering की quality इतनी अच्छी हो कि developers सच में उसे चुनें।

हम अब उस सीमा को पार कर चुके हैं। हर game के लिए नहीं। ray tracing वाले open-world AAA के लिए नहीं। पर games की एक तेज़ी से बढ़ती हुई श्रेणी, जिनमें real-time 3D, dynamic lighting, particle systems और photogrammetric assets शामिल हैं, उनके लिए browser एक व्यवहार्य target है। और native platforms के उलट, दूसरे छोर पर कोई 30% platform tax नहीं है।

सवाल कभी यह नहीं था कि "क्या browsers बराबरी कर पाएँगे।" सवाल था "कब।" मार्च 2026 ने इसका जवाब दे दिया।

संबंधित:

• Babylon.js 9.0: clustered lighting और gaussian splatting — पूरा technical विश्लेषण
• Chrome 146 ने WebGPU Compatibility Mode दिया — WebGPU install base का विस्तार
• Web game development WebGPU युग में प्रवेश करता है — हम यहाँ तक कैसे पहुँचे
• Web Game Engines की तुलना — Babylon.js, Three.js, PlayCanvas और बाकी सब
• Game developers के लिए WebGPU की शुरुआत — नए API के साथ hands-on
• Browser 3D Open World Tech — browser worlds के पीछे की rendering architecture

Oleg Sidorkin द्वारा, Cinevva के CTO

मार्च में तीन game engines सामने आए जो architecture के लिहाज़ से Unity/Unreal/Godot की पूरी वंशावली से अलग हैं। इनमें visual editor नहीं हैं। ये किसी इंसान के menus पर click करते जाने के लिए optimize नहीं किए गए हैं। ये शुरू से ही इस तरह बने हैं कि AI agents game state को पढ़ें, लिखें और control करें।

यह "AI tab वाला Unity" नहीं है। यह engine की एक अलग ही प्रजाति है।

AI पहले से ही 3D game development के workflows बदल रहा है। अब बारी engine layer की है।

तीनों engines

nAIVE Engine open-source है, Rust में लिखा गया है और WebGPU rendering के साथ आता है। एक सेकंड से कम का hot-reload: shaders 200ms से कम में, scenes 100ms से कम में, scripts 50ms से कम में। Scenes, pipelines और materials YAML में define किए जाते हैं, जिसका मतलब है कि LLMs उन्हें binary formats parse किए बिना पढ़ और generate कर सकते हैं। यह एक MCP command interface देता है जिससे AI agents JSON-RPC के ज़रिए engine functions को control कर सकते हैं। इसके साथ first-class Gaussian splatting और automated testing के लिए headless rendering आता है। पूरा architecture यह मानकर चलता है कि आपका primary user एक AI agent हो सकता है, mouse वाला कोई इंसान नहीं।

Arcane Engine एक code-first 2D engine है। Rust core, TypeScript scripting। visual editor बिल्कुल नहीं। इसका दर्शन है: "code ही scene है।" Game state एक scene tree के बजाय एक queryable database है। इसमें AI agent interaction के लिए एक built-in protocol शामिल है। Apache 2.0 licensed।

Mirror Engine alpha में है, और यह एक entity component system के साथ multiplayer-first है। दिलचस्प बात यह है: इसमें AI text-to-3D generation शामिल है जो text prompts से करीब 60 सेकंड में Gaussian splats बनाता है। TypeScript scripting, browser-आधारित "Mirror Lite" client।

ये तीनों engines न एक codebase साझा करते हैं न एक team, लेकिन इनकी design thesis एक ही है: किसी game engine का primary interface एक GUI नहीं, structured text होना चाहिए।

यह architecture क्यों मायने रखता है

पारंपरिक game engines एक desk पर बैठे इंसान की सेवा के लिए विकसित हुए। आपके पास एक viewport होता है। एक hierarchy panel। एक inspector। एक timeline। सब कुछ clicking, dragging और objects को visually रखने के इर्द-गिर्द design किया गया है। वह workflow ताक़तवर है। और यह एक AI agent के लिए इस्तेमाल करना नामुमकिन भी है।

जब आपका primary "user" एक LLM हो, तो आपको अलग primitives चाहिए। binary scene formats के बजाय YAML। nested scene trees के बजाय queryable state। mouse clicks के बजाय protocol-आधारित commands। window rendering के बजाय headless operation।

यह वही बदलाव है जो infrastructure में तब हुआ था जब DevOps GUI control panels से infrastructure-as-code की ओर बढ़ा। यही चीज़ अब game engines में हो रही है, बस बीस साल बाद।

nAIVE का MCP interface इसका सबसे साफ़ उदाहरण है। MCP (Model Context Protocol) तेज़ी से वह standard तरीका बनता जा रहा है जिससे AI agents tools के साथ बात करते हैं। जब कोई engine MCP को natively बोलता है, तो इस protocol को support करने वाला कोई भी AI agent scenes को बदल सकता है, parameters adjust कर सकता है, tests चला सकता है और बिना किसी इंसान के बीच में आए gameplay पर iterate कर सकता है। यह किसी पारंपरिक engine में ऊपर से जोड़ा गया feature नहीं है। यह engine और उसके user के बीच एक मौलिक रूप से अलग रिश्ता है।

Game development में Gaussian splatting। nAIVE और Mirror दोनों इसे एक first-class rendering primitive मानते हैं।

बड़ी तस्वीर

ये तीन engines अकेला signal नहीं हैं। Meshy के Black Box ने runtime पर AI-generated game mechanics दिखाए। OpenAI ने GDC में Phaser से बना एक tactical RPG दिखाया। "AI कुछ generate करता है" और "वह कुछ एक playable game की तरह चलता है" के बीच की tooling layer हर महीने पतली होती जा रही है।

Cinevva में, हम इस पुल को दूसरी दिशा से बना रहे हैं। हमारा engine rendering, physics और real-time interaction संभालता है जबकि AI asset generation संभालता है। यह तरीका nAIVE या Arcane से अलग है, लेकिन इसके पीछे का दांव वही है: भविष्य के game engine को AI को एक plugin की तरह जोड़ने के बजाय उसे पहली भाषा की तरह बोलना होगा।

पारंपरिक engine बनाने वाले भी यह जानते हैं। Unity ने GDC में AI game creation tools की झलक दिखाई। Roblox ने AI-powered 4D model creation launch किया। लेकिन इंसानों के लिए design किए गए engine में AI features जोड़ने और ऐसा engine design करने में, जहाँ AI ही primary interface हो, एक बड़ा फ़र्क़ है।

मेरे हिसाब से आगे क्या होगा

इनमें से ज़्यादातर engines टिकेंगे नहीं। किसी नई category के लिए यह सामान्य है। लेकिन design patterns टिकेंगे। YAML-आधारित scene definitions, agent control के लिए MCP protocols, queryable game state, headless operation। ये विचार दो साल के भीतर mainstream engines में समा जाएंगे।

इस दौर को जीतने वाला engine शायद अभी मौजूद ही नहीं है। लेकिन architectural DNA अभी इसी वक़्त लिखा जा रहा है, इन तीन projects में और कुछ और में। सवाल यह नहीं है कि game engines AI-native बनेंगे या नहीं। सवाल यह है कि यह बदलाव मौजूदा बड़ी कंपनियों के अंदर से आएगा या उन नए खिलाड़ियों से जिन्होंने पहले दिन से agents के लिए design किया।

संबंधित:

• अब हर कोई AI game engine बनना चाहता है — वह platform दौड़ जिसने मंच तैयार किया
• Frontier Open-Source Gen AI Models — वे models जिन्हें ये engines integrate कर रहे हैं
• Web Game Engines Comparison — नए engines बड़े ecosystem में कहाँ फ़िट होते हैं
• Open source में AI pollution की समस्या है — AI-generated contributions की लागत वाला पहलू

लेखक Oleg Sidorkin, Cinevva के CTO

दो हफ्ते पहले मैंने लिखा था कि vibe coding नया game jam है। थीसिस यह थी कि AI tools ने idea और prototype के बीच की रुकावट को खत्म कर दिया है। तब से, सबूत "लोग prototyping कर रहे हैं" से बदलकर "लोग बेच रहे हैं" तक पहुंच गया।

यह अब jam नहीं रहा। यह एक production methodology है।

AI agents के साथ पूरे video games बनाना। multi-agent workflow वही pattern है जो scale करता है।

मार्च में क्या ship हुआ

Void Balls को BigDevSoon ने 10 दिनों में बनाया। demo को जोड़-तोड़कर बनाने वाले 10 दिन नहीं। 173 scripts में फैली 29,000 लाइनों C#, 88 test files, पांच enemy types, 15 power-up cards, और boss fights वाला एक game बनाने के 10 दिन। workflow: 8 parallel Claude Code agents, हर एक एक अलग domain संभाल रहा था। Architecture, implementation, game balance, testing। सब एक साथ चल रहे थे। Art Replicate से आया, audio ElevenLabs से।

Grumbulus को दो डेवलपर ने दो शामों में बनाया। procedural audio और parallax rendering के साथ 15,000 लाइनें vanilla JavaScript, सब Claude Code से generate हुईं। कोई framework नहीं। कोई engine नहीं। बस AI plain JS लिख रहा था।

CODEX MORTIS Steam Early Access पर लॉन्च हुआ, जिसे खुद "दुनिया का पहला 100% AI-developed game" बताया गया। एक necromantic survival bullet hell जो तीन महीनों में बनाया गया, animations और shaders के लिए Claude Code से, artwork के लिए ChatGPT से। PIXI.js और bitECS के साथ pure TypeScript, Electron में लपेटा गया। demo ने 10,500 players खींचे, औसत session length 71 मिनट रही।

Catvivors Steam Early Access पर पहुंचा, बिल्लियों के बारे में एक Vampire Survivors-style roguelite। सोलो डेवलपर, AI researcher, ने पूरी चीज़ Claude Code से बनाई।

जो pattern मायने रखता है

अलग-अलग games दिलचस्प हैं। दोहराया जा सकने वाला pattern उससे ज़्यादा दिलचस्प है।

Void Balls के workflow पर ध्यान देना चाहिए क्योंकि यह एक इंसान का prompts टाइप करना नहीं है। यह आठ parallel AI agents हैं, हर एक की एक खास भूमिका है, सब एक ही codebase पर एक साथ काम कर रहे हैं। वह vibe coding नहीं है। वह orchestrated AI labor है। Architecture agent structure तय करता है। Implementation agents features बनाते हैं। Balance agent difficulty curves adjust करता है। Test agent test suites लिखता और चलाता है। एक इंसान आठ workers को directing कर रहा है।

यह वह workflow है जो scale करता है। "Claude से कहो कि game बना दे" नहीं, बल्कि "Claude agents की एक team को वैसे manage करो जैसे तुम डेवलपर की एक team को करते।" parallel agent pattern ही वह तरीका है जिससे तुम prototype से shippable product तक महीनों के बजाय दिनों में पहुंचते हो।

पूरा stack अब साबित हो चुका है: code generation + art generation + audio generation + game engine = shippable product। हर layer के लिए एक सक्षम tool है। codebase के लिए Claude Code। Art के लिए Replicate या Midjourney। audio के लिए ElevenLabs। अपना engine चुनो। इन tools के बीच का integration अभी भी कच्चा है, लेकिन यह काम करता है।

एक घंटे में scratch से एक 3D FPS vibe coding करना। कोई Unity नहीं, कोई Unreal नहीं, कोई engine नहीं।

ईमानदार सीमाएं

मैं इस छत के बारे में सीधी बात करूंगा क्योंकि मुझे लगता है कि hype हकीकत से आगे भाग रहा है।

CODEX MORTIS का औसत 71-मिनट session एक demo के लिए प्रभावशाली है। यह तुम्हें day-7 retention के बारे में कुछ नहीं बताता, या यह कि लोग पूरे game के लिए पैसे देंगे या नहीं। अब तक ship हुए games ज़्यादातर roguelikes, bullet hells, और auto-battlers हैं। ये वे genres हैं जिनमें procedural variation और mechanical depth systems के आपस में जुड़ने से आती है, handcrafted content से नहीं।

जो अभी तक नहीं दिखा: जटिल narrative games, गहरे strategy games, कुछ भी ऐसा जहां level design के लिए pacing और emotional arc के बारे में इंसानी समझ चाहिए। AI जिन genres को अच्छे से संभालता है वे वही हैं जो सबसे ज़्यादा systematizable हैं। यह कोई संयोग नहीं है।

"Shippable" और "खरीदने लायक" अलग चीज़ें हैं। एक free browser game और एक $15 Steam game के लिए quality का स्तर एक ही league में नहीं है। हमने वह retention data या revenue data नहीं देखा है जो तुम्हें बता सके कि AI-built games एक business को टिका सकते हैं या नहीं, सिर्फ एक launch को नहीं।

मुझे लगता है आगे क्या होगा

इनके जैसे और games ship होंगे। जैसे-जैसे AI models बेहतर होंगे और multi-agent workflows परिपक्व होंगे, quality सुधरेगी। पहली सच्ची hit, एक game जो मुख्य रूप से AI tools से बना हो और एक player base को टिकाए रखे और असली revenue पैदा करे, शायद 2026 के अंत से पहले आ जाएगी।

लेकिन जो चीज़ industry को बदलती है वह कोई एक game नहीं है। यह यह तथ्य है कि production methodology अब मौजूद है। हमने A Breaker Belt को दो लोगों के साथ तीन दिनों में बनाया। BigDevSoon ने Void Balls को एक इंसान और आठ agents के साथ 10 दिनों में बनाया। idea से shippable game तक पहुंचने की timeline games की एक बढ़ती हुई श्रेणी के लिए सालों से सिमटकर हफ्तों में आ गई है।

जिन studios को ध्यान देना चाहिए वे AAA houses नहीं हैं। वे mid-tier publishers हैं जो ऐसे games के लिए $20 लेते हैं जिन्हें एक सोलो डेवलपर अब एक महीने में बना सकता है।

संबंधित:

• Vibe coding नया game jam है — वह signal जिस पर यह आधारित है
• A Breaker Belt: Snake meets Arkanoid, तीन दिनों में vibe coded — AI workflow के साथ हमारा अपना अनुभव
• Agentic AI code tools — Claude Code, Cursor, और multi-agent development
• Game Jams और Hackathons — वह format जिससे vibe coding विकसित हो रहा है

लिखा Oleg Sidorkin, Cinevva के CTO ने

NVIDIA ने GDC में DLSS 5 को एक वादे के साथ launch किया: generative AI जो real-time में lighting, materials और shadows को फिर से बनाता है, जिससे games performance पर असर डाले बिना photorealistic दिखें। फिर लोगों ने देखा कि इसने character के चेहरों के साथ असल में क्या किया।

इंटरनेट ने इसे "yassifying" कहा। Resident Evil Requiem की Grace Ashcroft एक थकी-हारी, युद्ध में झुलसी survivor से बदलकर एक चिकने, एक-जैसे कर दिए गए चेहरे में बदल गई जो किसी अलग character जैसा दिखता था। Leon के साथ भी वही हुआ। AI ने तय कर लिया कि original art direction काफी अच्छी नहीं थी और उसे "fix" कर दिया।

Resident Evil Requiem के साथ NVIDIA का DLSS 5 reveal। visual बदलावों ने तुरंत backlash खड़ा कर दिया।

NVIDIA ने क्या भेजा और यह असल में क्या करता है

DLSS के version 1 से 4 तक upscaling technologies थीं। वे कम resolution पर render करती थीं और गायब pixels को भरने के लिए AI का इस्तेमाल करती थीं। Artists को ये पसंद थीं क्योंकि ये source image का सम्मान करती थीं। आपकी art direction बरकरार रहती थी। AI बस उसे और sharp बना देता था।

DLSS 5 मूल रूप से अलग है। यह एक video-to-video generative AI system है जो original game assets, geometry या scene data तक पहुंच के बिना काम करता है। यह render किया हुआ 2D frame और motion vectors लेता है, फिर "बेहतर" lighting, materials और detail के साथ एक नया frame बनाता है।

मुख्य शब्द है "बेहतर"। किसके फैसले के हिसाब से बेहतर? AI के। artist के नहीं।

NVIDIA ने शुरू में इसे "3D scene understanding" वाला बताया था। बाद में उन्होंने साफ किया कि यह सिर्फ 2D frame data से काम करता है। यह फर्क मायने रखता है। यह system artists ने जो बनाया उसे बेहतर नहीं कर रहा। यह एक flat image को समझकर वह बना रहा है जो उसके हिसाब से वहां होना चाहिए। जब इसे जानबूझकर रखी गई खामियों वाला कोई चेहरा मिलता है, scars, मैल, तनाव की रेखाएं, asymmetry, तो यह उन्हें चिकना करके हटा देता है क्योंकि इसका training data इन्हें "कम quality" से जोड़ता है।

यह creative control की समस्या है

52% developers जिन्होंने GDC को बताया कि उन्हें लगता है AI industry को नुकसान पहुंचा रहा है, वे सब अपनी नौकरी जाने की चिंता में नहीं हैं। उनमें से कई इस बात को लेकर चिंतित हैं कि उनका काम जब player तक पहुंचेगा तो वह कैसा दिखेगा, इस पर से उनका control खो जाएगा।

DLSS 5 इस डर को ठोस बना देता है। अब आपकी तैयार कला और player की screen के बीच की rendering pipeline में एक AI बैठा है, और वह सक्रिय रूप से आपके creative फैसलों को दोबारा लिख रहा है। जिस थके-हारे चेहरे को परफेक्ट करने में आपने हफ्ते लगाए, वह चिकना कर दिया जाता है। जिस moody lighting को आपने सावधानी से संतुलित किया, उसे ज़्यादा photorealistic बनाने के लिए "ठीक" कर दिया जाता है। आपने जो खास look चुना, उसे model जो "अच्छा" समझता है, उसमें generalize कर दिया जाता है।

Digital Foundry ने पहले एक positive preview छापा, फिर "Why We Should Have Waited With Our Coverage" शीर्षक वाला एक follow-up जारी किया। यहां तक कि वह tech press जो आमतौर पर NVIDIA की सराहना करती है, उसने भी माना कि इस release में कुछ अलग था।

Baldur's Gate 3 बनाने वाली Larian Studios ने कथित तौर पर fan backlash के बाद अपने अगले project के लिए कुछ generative rendering tools छोड़ दिए। जब एक studio जिसने अभी-अभी Game of the Year जीता है, मुफ्त rendering technology से दूर हट जाता है, तो creative control का तर्क सिर्फ theory नहीं रह जाता।

DLSS 5 बहस पर Digital Foundry का follow-up: "हमें और समय लेना चाहिए था।"

पैटर्न वही है

इसी महीने मैंने ओपन सोर्स में AI प्रदूषण पर लिखा था। पैटर्न बिल्कुल वही है। कुछ बनाना सस्ता है। कुछ अच्छा बनाना अब भी उतना ही महंगा है। यह आंकना कि कोई चीज़ अच्छी है या नहीं, अब भी उतना ही महंगा है।

ओपन सोर्स में यह AI से बने pull requests हैं जो ठीक-ठाक लगते हैं लेकिन सूक्ष्म bugs ले आते हैं। rendering में यह AI से बने frames हैं जो "बेहतर" दिखते हैं लेकिन वह नहीं हैं जो artist चाहता था। दोनों मामलों में AI सांख्यिकीय रूप से औसत निकाले गए output से इंसान के फैसले को ओवरराइड कर रहा है। दोनों मामले किसी और का समय और creative control खर्च कराते हैं।

फर्क यह है कि एक maintainer एक खराब PR को रिजेक्ट कर सकता है। एक artist DLSS 5 को रिजेक्ट नहीं कर सकता अगर NVIDIA और publisher इसे enable करने पर सहमत हो गए हों। player का GPU उनके काम को real time में दोबारा लिख रहा है, और उनकी कोई बात नहीं चलती।

मुझे लगता है आगे क्या होगा

NVIDIA fall 2026 में DLSS 5 भेजेगा। Capcom, Bethesda, Ubisoft और Warner Bros. समेत बड़े publishers पहले ही साइन कर चुके हैं। technology बेहतर होती जाएगी और "yassifying" कम साफ दिखने लगेगी। backlash शांत हो जाएगा क्योंकि लोग चीज़ों के आदी हो जाते हैं।

लेकिन नीचे छिपा सवाल नहीं जाएगा: जब आप rendering pipeline में generative AI जोड़ते हैं, तो player जो देखता है उस पर आखिरी फैसला किसका होता है? अभी, जवाब है NVIDIA का training data। यह बात हर उस इंसान को परेशान करनी चाहिए जो games को एक कला रूप के तौर पर अहमियत देता है।

यह फर्क इस बात के लिए मायने रखता है कि हम पूरी industry में AI tools के बारे में कैसे सोचते हैं। जो AI creator के इरादे की सेवा करता है, वह एक tool है। जो AI creator के इरादे को ओवरराइड करता है, वह कुछ बिल्कुल अलग है। DLSS 1 से 4 tools थे। DLSS 5 पहला mainstream उदाहरण है जहां AI hardware स्तर पर, बिना पूछे, किसी और की कला में अपना खुद का सौंदर्य-बोध वाला फैसला घुसा देता है।

संबंधित:

• ओपन सोर्स में AI प्रदूषण की समस्या है — अलग संदर्भ में वही पैटर्न
• GDC 2026 आंकड़ों में — AI के विरोध पर developers का survey data
• AI controversy, भरोसा और post-AI economy — भरोसे का बड़ा सवाल
• Frontier Open-Source Gen AI Models — generative rendering को चलाने वाले models

लेखक Oleg Sidorkin, Cinevva के CTO

Andrej Karpathy ने फरवरी 2025 में "vibe coding" शब्द गढ़ा था, यह बताने के लिए कि software कैसे बनाया जाए, आप बस यह बताते हैं कि आपको क्या चाहिए और implementation का काम AI संभाल लेता है। एक साल बाद, Collins Dictionary ने इसे अपना Word of the Year बना दिया। उस वसंत में इस शब्द की searches 6,700% बढ़ गईं।

ज्यादातर software के लिए vibe coding का मतलब है तेज prototyping। Game development के लिए इसका मतलब कुछ और खास है। "अजीब idea" और "playable prototype" के बीच की दीवार गिर गई।

A Breaker Belt: Snake और Arkanoid का मेल, Cinevva Engine पर तीन दिन में vibe coded किया गया

असल में क्या बदला

Game jams इसलिए मौजूद हैं क्योंकि ज्यादातर experiments के लिए game development में बहुत समय लगता है। आपको मिलते हैं 48 घंटे, एक theme, और जितनी energy आप caffeine और adrenaline पर टिका सको। यह बाधा creativity को मजबूर करती है। आप कुछ बहुत बड़ा नहीं बना सकते, इसलिए आप कुछ अजीब बनाते हैं। इतिहास के कुछ बेहतरीन games jam projects के तौर पर शुरू हुए थे।

Vibe coding कुछ ऐसा ही करती है, पर बनावटी समय के दबाव को हटा देती है। जब किसी mechanic, mood, या behavior को बताने भर से आपको दिनों के बजाय मिनटों में एक working prototype मिल जाता है, तो आप ऐसे ideas आज़मा सकते हैं जिन्हें कोई हरी झंडी नहीं देता। experimentation का अर्थशास्त्र बदल गया।

हमने A Breaker Belt को तीन दिन में बनाया। दो लोग, रुक-रुक कर, बिना crunch किए। Snake और Arkanoid का मेल। 50 waves। 23 brick types। Reactive music। AI narration। Real-time synthesized sound effects। Web, mobile, और PC पर ship किया। इतने scope में आमतौर पर आठ या नौ लोगों की team को कई महीने लगते। वह अजीब mashup जो एक brainstorm doc में ही दम तोड़ देता, उसके बजाय एक लंबे weekend में बन गया।

Vibe coding games के लिए यही असल में करती है। यह बेहतरीन games अपने-आप नहीं बना देती। यह experiments को सस्ता बना देती है।

इस trend के पीछे के आंकड़े

Investment से आपको पता चलता है कि industry इसे कितनी गंभीरता से ले रही है। Cursor ने Series D में $2.3 billion जुटाए। Lovable ने $6.6 billion valuation पर $330 million जुटाए। अनुमान है कि Y Combinator के Winter 2025 के 25% startups ऐसे codebases पर चल रहे थे जो 95% AI-generated हैं।

खास तौर पर game development में, Three.js अब vibe-coded web games के लिए मुख्य library है, जिसके हर हफ्ते npm पर 2.7 million downloads होते हैं। Cinevva, Phaser, और AI tools की बढ़ती सूची जैसे platforms ऐसे development environments बना रहे हैं जहां intent बताना ही मुख्य input है।

Karpathy खुद पहले ही अगले concept की ओर बढ़ चुके हैं। वे इसे "agentic engineering" कह रहे हैं, जहां AI agents human prompts का जवाब देने के बजाय खुद code लिखते हैं। "इसमें एक कला, विज्ञान और expertise है," उन्होंने लिखा। यह field शब्दावली से तेज चल रही है।

क्या नहीं बदलता

सीमाएं असली हैं और इनके बारे में ईमानदार रहना ज़रूरी है। जैसे-जैसे projects बढ़ते हैं, context management ही अड़चन बन जाता है। जब आपका project इतना जटिल हो जाता है कि पूरा context एक ही window में नहीं समाता, तो AI model का performance गिरने लगता है। जो code आपको मिलता है वह अक्सर चलाने भर के लिए तो अच्छा होता है पर maintain करने के लिए नहीं। जब कुछ टूटता है, तो AI-generated जटिलता का debugging करना, जिसे कोई पूरी तरह समझता ही नहीं, अपने आप में एक खास चुनौती है।

एक taste की समस्या भी है। AI बहुत जल्दी एक mechanically काम करने वाला game बना सकता है। पर यह आपको नहीं बता सकता कि game मज़ेदार है या नहीं। कि difficulty curve सही लगता है या नहीं। कि music mood से मेल खाता है या नहीं। कि pacing आपको बांधे रखती है या धीरे-धीरे bore कर देती है। judgment की वह परत, वही चीज़ जो एक prototype को खेलने लायक game से अलग करती है, अब भी एक ऐसे इंसान की मांग करती है जिसे नतीजे की परवाह हो।

Game jams इसलिए काम करते हैं क्योंकि समय का दबाव आपको यह कठिन फैसला लेने पर मजबूर करता है कि क्या मायने रखता है। Vibe coding समय का दबाव हटा देती है पर फैसलों की ज़रूरत नहीं। सबसे अच्छे vibe-coded games उन लोगों से आएंगे जो जानते हैं कि उन्हें क्या चाहिए, न कि उन लोगों से जो जो भी वापस आए उसे स्वीकार कर लेते हैं।

मुझे लगता है आगे क्या होगा

ऐसे और games मौजूद होंगे जिन्हें मौजूद नहीं होना चाहिए था। उनमें से कुछ बहुत खराब होंगे। कुछ शानदार होंगे। अनुपात शायद न बदले, पर मात्रा बदलेगी। और उस मात्रा में आपको ऐसे games मिलेंगे जो पहले कभी नहीं बन सकते थे। ऐसे genres जिनके अभी नाम भी नहीं हैं। ऐसे mashups जिन्हें कोई fund नहीं करता। ऐसे personal projects जो एक इंसान ने इसलिए बनाए क्योंकि tools आखिरकार रास्ते से हट गए।

बेहतर tools का वादा हमेशा यही रहा है। यह नहीं कि सब कुछ बेहतर हो जाएगा, बल्कि यह कि और भी चीज़ें मौजूद हो पाएंगी। game jam वाली energy, वह "चलो बस इसे आज़माकर देखते हैं," अब 48 घंटे की एक खिड़की तक सीमित नहीं है। मंगलवार की दोपहर है और आपके पास एक idea है। गुरुवार तक, वह खेलने लायक है।

Cinevva का engine इस्तेमाल करने के लिए मुफ्त है। आपका अजीब game idea शायद मौजूद होने से सिर्फ तीन दिन दूर है।

संबंधित:

• A Breaker Belt: Snake और Arkanoid का मेल, तीन दिन में vibe coded
• हमें एक radio station बनाने की उम्मीद नहीं थी
• Agentic AI code tools — game development के लिए Claude Code, Cursor, और GitHub Copilot
• Game Jams और Hackathons — game बनाने का असली 48-घंटे वाला format
• Web Game Engines Comparison — ऐसे engines जो AI-assisted workflows के साथ अच्छे से मेल खाते हैं

लेखक Oleg Sidorkin, Cinevva के CTO

Steam Next Fest सिर्फ एक इवेंट नहीं है। यह एक डेटासेट है। फरवरी 2026 में 2,200 से ज़्यादा games अपने demos, trailers और wishlists की उम्मीदों के साथ आए। नतीजे सामने हैं, और वे उस बात की पुष्टि करते हैं जिसे indie developers महसूस तो करते हैं पर हमेशा खुलकर नहीं कहते।

Next Fest उन games को इनाम देता है जिनके पास पहले से ऑडियंस होती है। अगर आप शून्य से शुरू कर रहे हैं, तो अकेला फेस्टिवल इसे नहीं बदलेगा।

Steam Next Fest फरवरी 2026 के बेहतरीन indie games

आंकड़े

presskit.gg ने डेटा का विश्लेषण किया और इसके स्तर काफ़ी साफ़ हैं:

माध्यिका game ने 460 wishlists कमाए। और यह तब, जब एक demo उपलब्ध था, एक store page लाइव था, और Steam खुद इस इवेंट का सक्रिय रूप से प्रचार कर रहा था। धरती के सबसे बड़े PC gaming platform पर एक हफ़्ते की समर्पित दिखावट के बदले चार सौ साठ wishlists।

गति बढ़ती जाती है। गुमनामी भी बढ़ती जाती है।

Diamond स्तर के लगभग सभी games ने 10,000+ मौजूदा wishlists के साथ शुरुआत की थी। फेस्टिवल शुरू होने से पहले ही उन्हें content creator कवरेज मिल चुकी थी। उनकी capsule art thumbnail साइज़ पर भी तुरंत बात कह देती थी। उन्होंने आने से पहले ही marketing का काम कर लिया था।

और जो games 1,000 से कम wishlists के साथ आए? उन्हें ज़्यादातर बस कुछ सौ और मिले। फेस्टिवल ने उसी चीज़ को बढ़ाया जो पहले से मौजूद थी। उसने शून्य से कुछ नहीं बनाया।

यह पैटर्न सिर्फ़ Next Fest तक सीमित नहीं है। यह discovery में हर जगह दिखता है। YouTube उन videos की सिफ़ारिश करता है जो पहले से अच्छा कर रहे हैं। Spotify उन गानों को सामने लाता है जिन्हें पहले से सुना जा रहा है। हर जगह के store algorithms एंगेजमेंट को और ज़्यादा एंगेजमेंट से इनाम देते हैं।

अगर आपके पास गति है, तो Next Fest एक गुणक है। अगर नहीं है, तो यह बस एक भागीदारी प्रमाणपत्र है।

Genre उससे ज़्यादा मायने रखता है जितना आप सोचेंगे

Co-op games ने हर मोर्चे पर बेहतर प्रदर्शन किया। Content creators stream पर दोस्तों के साथ खेलना चाहते हैं। वह सामाजिक गतिशीलता clips पैदा करती है, जो views पैदा करती है, जो wishlists पैदा करती है। सामाजिक खेल का चक्र सोशल मीडिया के चक्र को आगे बढ़ाता है।

Survival और crafting games मज़बूत बने रहे, भले ही developer की तरफ़ से यह genre कितना भी भरा हुआ लगे। players अब भी ये games चाहते हैं। आपूर्ति ने मांग को पार नहीं किया है।

Narrative games और visual novels को संघर्ष करना पड़ा। Next Fest का स्वरूप उनके ख़िलाफ़ काम करता है। Demo ब्राउज़ करना तेज़ दृश्य स्पष्टता को इनाम देता है। आपको किसी game की capsule art देखने और शायद दस सेकंड का gameplay देखने के कुछ ही पलों में समझ आ जाना चाहिए कि वह game क्या है। कहानी पर आधारित games को ऐसे संदर्भ की ज़रूरत होती है जो thumbnails नहीं दे सकतीं।

Roguelikes अब भी सफल हो सकते हैं, पर सिर्फ़ मज़बूत अलगाव के साथ। "यह एक twist वाला roguelike है" में उस twist का एक नज़र में दिखना ज़रूरी है।

हम इसे ध्यान से क्यों देख रहे हैं

यह डेटा हमारे लिए मायने रखता है क्योंकि Cinevva को ख़ास तौर पर उसी समस्या के लिए बनाया गया था जो यह उजागर करता है। हमारी reels-first discovery असली gameplay दिखाती है, छांटे गए screenshots नहीं। आप clips स्क्रॉल करते हैं, कुछ ऐसा देखते हैं जो मज़ेदार लगता है, और आप उसे अपने browser में तुरंत खेल रहे होते हैं।

हम Steam को बदलने या Next Fest से मुक़ाबला करने की कोशिश नहीं कर रहे। डेटा हमें बताता है कि ये platforms उन games के लिए बढ़िया काम करते हैं जिनके पास पहले से दिखावट है। हमें जिस सवाल की परवाह है वह यह है: बाकी 2,000 games का क्या होता है? वे जो सचमुच अच्छे हैं पर जो किसी मौजूदा ऑडियंस के साथ नहीं आए?

उन games को एक ऐसे discovery रास्ते की ज़रूरत है जो पहले से मौजूद गति पर निर्भर न करे। कोई ऐसी जगह जहां कोई player ऐसे game पर अचानक पहुंच जाए जिसे वह किसी store में कभी न ढूंढ़ पाता, क्योंकि उसने उसके पांच सेकंड देखे और वह दिलचस्प लगा। यही वह खाई है जिसे हम भरने के लिए बना रहे हैं।

इस साल की शुरुआत में हमने जो Steam Next Fest रणनीति गाइड प्रकाशित की थी, वह व्यावहारिक पहलू को कवर करती है। यह लेख संरचनात्मक निष्कर्ष के बारे में है। PC gaming के सबसे बड़े platform पर discovery तेज़ी से एक अमीर-और-अमीर-बनो वाली व्यवस्था बनती जा रही है। अगर यही एकमात्र व्यवस्था है, तो बहुत सारे शानदार games अदृश्य ही रह जाएंगे।

संबंधित:

• Steam Next Fest फरवरी 2026 का डेटा
• Steam Next Fest रणनीति गाइड — Next Fest को अपने लिए काम में लाने की रणनीतियां
• Co-op Game Design — co-op games फेस्टिवल में लगातार बेहतर प्रदर्शन करते हैं
• अपने game को itch.io पर कैसे लॉन्च करें — छोटे games के लिए एक वैकल्पिक discovery रास्ता

लिखा Oleg Sidorkin, Cinevva के CTO ने

Rémi Verschelde उन लोगों में से एक हैं जो Godot को चलाते रहते हैं। किसी साइड प्रोजेक्ट या शौक के तौर पर नहीं। एक जीवन भर के काम के तौर पर। ज़्यादातर लोगों के इसके बारे में सुनने से भी पहले से वे इस engine को maintain कर रहे हैं, contributions की समीक्षा कर रहे हैं, patches merge कर रहे हैं, और यह पक्का कर रहे हैं कि जिस चीज़ पर लाखों developers निर्भर हैं वह सचमुच काम करे।

पिछले महीने उन्होंने बताया कि Godot की contribution pipeline के साथ जो हो रहा है वह "थकाने वाला और हतोत्साहित करने वाला" है।

वजह: AI से बने pull requests। बहुत सारे।

Godot के पास अभी GitHub पर 4,681 open pull requests हैं। नए submissions का एक बढ़ता हुआ हिस्सा उन लोगों से आता है जिन्होंने एक prompt टाइप किया, कुछ code पाया, और बिना यह समझे कि वह करता क्या है उसे submit कर दिया। पहली नज़र में यह code अक्सर ठीक-ठाक लगता है। यह compile होता है। variable के नाम समझ में आते हैं। फिर एक maintainer बीस मिनट लगाकर पता लगाता है कि यह एक सूक्ष्म bug ले आता है, किसी edge case को तोड़ देता है, या ऐसी समस्या हल करता है जो है ही नहीं।

खराब PRs को नकारने में लगाया गया समय अच्छे PRs की समीक्षा में नहीं लग पाता।

विडंबना खुद-ब-खुद लिख जाती है

AI tools का मकसद developers को ज़्यादा productive बनाना है। यही pitch है। इसीलिए कंपनियां इन्हें बनाने के लिए अरबों जुटा रही हैं। और एक व्यक्ति के स्तर पर ये ऐसा करते भी हैं। मैं रोज़ AI tools इस्तेमाल करता हूं। हमारा पूरा platform game बनाने, music जेनरेट करने, 3D models और बहुत कुछ के लिए AI का इस्तेमाल करता है। मैं AI के खिलाफ़ नहीं हूं।

लेकिन एक system-level असर है जिसकी बात investor decks में कोई नहीं करता। जब AI किसी contribution को जेनरेट करना बेहद आसान बना देता है, और submit करने की लागत शून्य तक गिर जाती है, पर समीक्षा करने की लागत ठीक वहीं रहती है जहां थी, तो आपको एक प्रदूषण की समस्या मिलती है।

ये PRs submit करने वाले लोग दुर्भावना से ऐसा नहीं करते। उनमें से ज़्यादातर सचमुच contribute करना चाहते हैं। उन्हें बताया गया है कि AI tools उन्हें गहरी विशेषज्ञता के बिना ओपन सोर्स में योगदान करने देते हैं। और ये tools उन्हें कुछ ऐसा जेनरेट करने तो देते हैं जो एक contribution जैसा दिखता है। बस वह contribution होता नहीं।

Verschelde ने माना कि AI से बने PRs पकड़ने के लिए AI का इस्तेमाल करना "बेहद विडंबनापूर्ण" होगा। वे सही हैं। AI के output से AI detection के ज़रिए लड़ना एक ऐसी होड़ है जिसे कोई नहीं जीतता।

यह असल में हमें क्या बताता है

कुछ बनाना अब सस्ता है। कुछ अच्छा बनाने की लागत आज भी उतनी ही है।

यही सबक हर जगह दिख रहा है, सिर्फ़ ओपन-सोर्स code review में नहीं। यह game development में दिखता है, music production में दिखता है, content बनाने में दिखता है। AI ने फ़र्श नीचे गिरा दिया। न्यूनतम चलने लायक contribution, न्यूनतम चलने लायक game, न्यूनतम चलने लायक blog post अब सेकंडों में जेनरेट हो सकता है। पर छत वहीं रही।

जो लोग अपने काम में पहले से अच्छे थे वे अब तेज़ हैं। "एक चीज़ बनाई" और "किसी के समय के लायक चीज़ बनाई" के बीच का फ़ासला असल में पहले से ज़्यादा चौड़ा है, क्योंकि औसत दर्जे के output की मात्रा फूट पड़ी है जबकि जो लोग quality को परख सकते हैं उनकी संख्या नहीं बदली।

Godot की contribution guidelines में AI सहायता का खुलासा करना ज़रूरी है। लोग उन्हें नज़रअंदाज़ करते हैं। आप नियमों को सख्त बना सकते हैं, पर इन्हें लागू करने के लिए वही human review का समय चाहिए जिसे आप बचाने की कोशिश कर रहे हैं।

असली समाधान उबाऊ है

Verschelde की मुख्य मांग funding है। और maintainers रखें। ज़्यादा इंसान काम की समीक्षा करें। यह कोई तकनीकी समाधान नहीं है। यह एक संगठनात्मक समाधान है। और शायद यही एकमात्र समाधान है जो काम करता है।

ओपन-सोर्स प्रोजेक्ट्स को वही सबक मिल रहा है जो हम बाकी सब सीख रहे हैं: AI इंसानी समझ की ज़रूरत को खत्म नहीं करता। यह उसे बढ़ाता है। जितना ज़्यादा AI से बना content किसी भी system में बहता है, उतने ही ज़्यादा आपको ऐसे लोग चाहिए जो उस चीज़ में फ़र्क बता सकें जो सही दिखती है और उस चीज़ में जो सही है।

Cinevva के tools बनाते समय हम इस बारे में लगातार सोचते हैं। मकसद कभी भी game बनाने से इंसानी समझ को हटाना नहीं था। मकसद रचनात्मक लोगों को अपनी समझ उस पर केंद्रित करने देना है जो मायने रखता है: क्या यह सही लगता है, क्या यह काम करता है, क्या किसी को इसमें मज़ा आएगा? मेहनत वाला काम संभाल लिया जाता है। स्वाद को automate नहीं किया जाता।

Godot इसका हल निकाल लेगा। यह engine बहुत अहम है और community बहुत मज़बूत है कि ऐसा न हो। पर वे जिस पैटर्न से जूझ रहे हैं वह जाने वाला नहीं है। हर ओपन-सोर्स प्रोजेक्ट, हर रचनात्मक platform, हर वह system जो जनता से contributions लेता है, इसी सवाल का सामना करेगा: आप ऐसी दुनिया को कैसे संभालते हैं जहां कुछ बनाना लगभग मुफ़्त है पर उसे परखना नहीं?

संबंधित:

• Agentic AI code tools — AI coding tools का ज़िम्मेदार इस्तेमाल
• Frontier Open-Source Gen AI Models — इस बदलाव को चलाने वाले ओपन-सोर्स models
• AI controversy, trust, and the post-AI economy — रचनात्मक काम में AI के इर्द-गिर्द भरोसे का बड़ा सवाल
• Web Game Engines Comparison — Godot और इस ट्रेंड से प्रभावित दूसरे engines

Oleg Sidorkin द्वारा, Cinevva के CTO

फरवरी 2026 में, ये सब चीज़ें एक-दूसरे के लगभग तीन हफ़्तों के अंदर हुईं।

Unity के CEO ने आधिकारिक तौर पर कहा कि वे GDC में prompt-to-game demo करेंगे। Roblox ने एक 4D creation tool launch किया जो text से interactive objects बनाता है। Moonlake AI ने अपने Generative Game Engine का beta खोला, जिसे Nvidia, Jeff Dean और YouTube के co-founder से मिले $30 million का समर्थन था। Phaser Editor v5 launch हुआ, जिसमें AI सीधे scene editor में MCP के ज़रिए बना हुआ था। और कम से कम आधा दर्जन ऐसे startups Product Hunt पर आ गए जिनका नाम मैंने पहले कभी नहीं सुना था, सबका कोई न कोई रूप था "एक game describe करो, हम उसे बना देंगे।"

Roblox के VP of AI अपने Cube foundation model और 4D creation पर

यह कोई शिकायत नहीं है। यह timing के बारे में एक observation है।

दो साल पहले, जब हम pitch कर रहे थे कि Cinevva क्या करता है, तो Sequoia, Pear, Draper और दर्जनों दूसरी firms के VCs ने हमें बताया कि बाज़ार है ही नहीं। B2C game creation? Indies tools के लिए पैसे नहीं देते। आप capability को खत्म किए बिना game development को आसान नहीं बना सकते। आपत्तियों का वही standard deck, जिसे market analysis के रूप में सजा दिया गया था।

अब gaming के सबसे बड़े नाम सैकड़ों millions खर्च करके उसी चीज़ के variations बनाने की दौड़ में हैं जिसके बारे में वे कहते थे कि यह काम नहीं कर सकती।

ये tools एक जैसी चीज़ नहीं हैं

यहाँ वह है जो मायने रखता है और जो ज़्यादातर coverage छोड़ देती है। "AI game creation" एक ऐसा umbrella शब्द है जो मूल रूप से अलग-अलग products को छिपा देता है।

Text-to-demo tools ऐसा कुछ बनाते हैं जो tweet में प्रभावशाली दिखता है। आप एक prompt type करते हैं, एक playable चीज़ पाते हैं, GIF share करते हैं। output असली है, लेकिन यह एक demo है। उस demo से उस game तक पहुँचना जिसे कोई एक घंटे तक खेले, पूरी तरह से एक अलग समस्या है। Moonlake और कुछ नए startups यहीं रहते हैं। वे शुरुआती चिंगारी को हल कर रहे हैं।

AI copilot tools एक मौजूदा engine के अंदर बैठते हैं और आपको तेज़ी से काम करने में मदद करते हैं। MCP के साथ Phaser Editor v5 यही करता है। Ziva, Godot के लिए यही करता है। वे development process की जगह नहीं लेते, उसे तेज़ करते हैं। आपको अभी भी समझना पड़ता है कि आप क्या बना रहे हैं। AI मेहनत वाला काम संभालता है।

Platform-native AI creation वह है जो Roblox 4D के साथ कर रहा है। AI runtime में embedded है। objects सिर्फ़ सही नहीं दिखते, वे सही व्यवहार करते हैं क्योंकि generation model platform के physics और interaction systems को समझता है। इसका tradeoff: आप उस platform से बंधे रहते हैं।

Full-stack AI game engines concept से लेकर shipping तक सब कुछ संभालने की कोशिश कर रहे हैं। Unity GDC के लिए यही वादा कर रहा है। Cinevva में हम सालों से यही बना रहे हैं। बताओ कि आप क्या चाहते हो, जो जवाब आए उस पर iterate करो, web, mobile, desktop, Steam पर ship करो। जो game आप prompt करते हो वही game आप publish करते हो।

Phaser Editor v5, scene-level सहायता के लिए MCP के ज़रिए AI को जोड़ता है

demo और ship के बीच का फ़ासला

इस space का हर tool ऐसी चीज़ बना सकता है जो चलती हो। वह हिस्सा जल्दी आसान हो गया। मुश्किल हिस्सा उसके बाद का सब कुछ है। क्या game phone पर अच्छा लगता है? क्या यह edge cases को संभालता है? क्या आप music, difficulty curve, pacing पर iterate कर सकते हो? क्या आप एक ही project से पाँच platforms पर इसे ship कर सकते हो? क्या AI समझता है कि एक game को असल में मज़ेदार क्या बनाता है, बनाम क्या एक screenshot को cool दिखाता है?

इनमें से कुछ घोषणाएँ असली products में बदल जाएँगी। कुछ को funding का एक round मिल जाएगा, अच्छे demos बना लेंगी, और चुपचाप गायब हो जाएँगी जब "एक असली game ship करो" वाला हिस्सा "एक prototype बनाओ" वाले हिस्से से ज़्यादा मुश्किल साबित होगा।

मुझे लगता है असल में क्या हो रहा है

जो market validation हमें Sand Hill Road की किसी meeting में नहीं मिल पाई, वह अब खुद industry से आ रही है। जब Unity और Roblox अपने roadmaps को AI creation पर दांव पर लगाते हैं, तो वे उसी बात की पुष्टि कर रहे हैं जिसकी ओर हम काम करते आए हैं: tools को इस हिसाब से ढलना चाहिए कि creative लोग कैसे सोचते हैं।

यह दौड़ इस बारे में नहीं है कि सबसे पहले कौन घोषणा करता है। यह इस बारे में है कि कौन ऐसा कुछ ship करता है जिसे लोग असल में ऐसे games बनाने के लिए इस्तेमाल करें जिन पर उन्हें गर्व हो। हज़ारों लोग आज Cinevva पर यही कर रहे हैं। A Breaker Belt दो लोग और तीन दिन था। Cinevva Radio में community द्वारा बनाए गए 362 tracks हैं। भविष्य बनाने का वादा करने और उसमें पहले से जीने के बीच यही फ़र्क है।

competition अच्छी है। इसका मतलब है कि बाज़ार मौजूद है। हम यह काफ़ी समय से जानते हैं।

संबंधित:

• Web Game Engines की तुलना — पारंपरिक engines web output पर कैसी तुलना करती हैं
• Frontier Open-Source Gen AI Models — game generation को चलाने वाले AI models
• Agentic AI code tools — AI copilot layer जो development को तेज़ करती है
• A Breaker Belt — AI tools के साथ तीन दिनों में बना एक game