wishlists, demos और timing के बारे में data क्या कहता है। 200+ games के असली आंकड़े।

अगर आप कैलेंडर के हिसाब से प्लान कर रहे हैं, तो Steam 2026 में Next Fest तीन बार चलाता है: 23 फरवरी से 2 मार्च (हो चुका), 15 से 22 जून, और 19 से 26 अक्टूबर। जून और अक्टूबर के editions शुरुआती दिन सुबह 10:00 AM PDT से अंतिम दिन सुबह 10:00 AM PDT तक चलते हैं, और ठीक Summer और Winter sales से पहले आते हैं (फरवरी भी Pacific time पर चला, daylight saving से पहले)। एक game कभी भी सिर्फ एक ही Next Fest में शामिल हो सकती है, इसलिए वो edition चुनें जो आपकी release window से मेल खाता हो। fest खुलने तक आपका demo सार्वजनिक रूप से खेलने लायक होना चाहिए, और fest बंद होने के बाद ही आप release कर सकते हैं।

Next Fest के बारे में बात यह है: हर कोई इसे लॉटरी की तरह मानता है। अपना demo डाल दो, उंगलियाँ क्रॉस कर लो, और उम्मीद करो कि algorithm आप पर मेहरबान हो जाए। पर यह ऐसे काम नहीं करता।

मैं postmortems को जुनून की हद तक पढ़ता रहा हूँ। अकेले 2025 के ही सैकड़ों। पैटर्न इतना एक जैसा है कि लगभग बोरिंग लगता है: जो games Next Fest में "जीतती" हैं वे festival के दौरान सफलता खोज नहीं रही होतीं। वे उस momentum को बढ़ा रही होती हैं जो उन्होंने पहले ही बना लिया था।

मैं आपको दिखाता हूँ कि मेरा मतलब क्या है।

वो फॉर्मूला जो कोई सुनना नहीं चाहता

पहले की Wishlists × 2 = मिली हुई Wishlists

यह अनुपात postmortem दर postmortem में दिखता है।

Eilean Mor अक्टूबर 2025 में 2,117 wishlists के साथ उतरी। festival के दौरान 2,082 हासिल कीं। लगभग ठीक 2×।

[IMAGE: Eilean Mor trailer screenshot or embed - https://www.youtube.com/watch?v=jFv7SjsQEws]

Dice of Kalma 335 wishlists के साथ उतरी। 659 हासिल कीं। 2× से थोड़ा कम। उनके developer ने लिखा: "हमारी wishlists लगभग तीन गुना हो गईं, जो शानदार है, पर अभी भी हमें बहुत काम करना है।"

यही असहज सच्चाई है। Next Fest उसी को दोगुना करता है जो आपके पास पहले से है। अगर आपके पास कुछ नहीं है, तो आपको शून्य का दोगुना मिलता है।

2,000 Wishlist की चट्टान

फरवरी 2025 की 208 games के data से पता चलता है कि 2,000 wishlists पर एक तीखा मोड़ आता है।

उस सर्वे के एक developer ने यह कहा: "आप सच में देखना शुरू करते हैं कि Steam Next Fest से पहले जिन games के पास 2000+ wishlists होती हैं, उनके लिए कमाई गई wishlists कैसे आसमान छूने लगती हैं।"

यह बिल्कुल algorithm की बात नहीं है। यह validation की बात है। 2,000 wishlists का मतलब है कि आपने marketing के बारे में कुछ समझ लिया है। आप जानते हैं कि लोगों तक कैसे पहुँचना है। यह कौशल festival के दौरान कई गुना हो जाता है।

पहले 48 घंटे ही सब कुछ हैं

Valve दिन 1 और 2 को सबको एक मौका देता है। उसके बाद, algorithm performance के आधार पर तय करता है कि किसे ज्यादा visibility का हक है।

Bronze tier की games? उनके impressions दिन 3 को चट्टान से गिर जाते हैं। Diamond tier की games? उनके impressions तीन गुना हो जाते हैं।

दिन 1-2: सब कुछ झोंक दो। Stream करो। Post करो। creators के साथ तालमेल बिठाओ। दिन 3+: algorithm पहले ही तय कर चुका है। अब आप बस सवारी का हिस्सा हैं।

2025 में असल में क्या जीता

Do No Harm (फरवरी 2025)

[IMAGE: Do No Harm trailer screenshot or embed - https://www.youtube.com/watch?v=GBlOHAL1LkY]

आंकड़े: Next Fest के दौरान 45,655 wishlists मिलीं। 52,102 के साथ शुरुआत की।

उन्होंने क्या किया:

• Trailer 29 जनवरी को GameTrailers पर आया (Next Fest से हफ्तों पहले)
• PR आउटरीच trailer के साथ timed किया गया
• Demo 4 फरवरी को live हुआ
• organic momentum को बढ़ाने के लिए paid ads

यही playbook है। उन्होंने खुद को खोजे जाने के लिए Next Fest पर भरोसा नहीं किया। उन्होंने Next Fest का इस्तेमाल पहले से कमाए हुए ध्यान को कई गुना करने के लिए किया।

Cairn (अक्टूबर 2025)

[IMAGE: Cairn trailer screenshot or embed - https://www.youtube.com/watch?v=x6KWhvvk3bM]

दिन 1 को Popular Upcoming पर #5 पहुँची। दिन 2 तक Top Demos और Trending Upcoming में।

उन्होंने क्या किया:

• Demo दिसंबर 2024 में launch हुआ (उनके Next Fest से 10 महीने पहले)
• festival से पहले 32,000 followers
• Next Fest से पहले 18 festivals में स्वीकार की गई
• The Game Bakers (Furi, Haven) - एक स्थापित studio जिसका ट्रैक रिकॉर्ड था

उन्हें Next Fest की जरूरत नहीं थी। पर उन्होंने फिर भी इसका इस्तेमाल किया क्योंकि जब आप काम पहले ही कर चुके होते हैं तो यह मुफ्त का amplification है।

YAPYAP (अक्टूबर 2025)

[IMAGE: YAPYAP gameplay screenshot or embed - https://www.youtube.com/watch?v=7d8Fd9XXAtQ]

"friend slop" वाला तमाशा। Co-op horror जहाँ आप wizards बनकर एक tower में तोड़फोड़ करते हैं। social media पर viral हुई, फिर Next Fest पर छा गई।

उनका trailer 25 अगस्त 2025 को आया - Next Fest से एक महीने पहले। इसने 434K views कमाए। वही मोड़ था। उसके बाद जो कुछ हुआ वो बस लहर पर सवारी थी।

फरवरी 2026 ने क्या पुष्टि की

फरवरी 2026 के edition ने playbook बदला नहीं, बल्कि उसे और पक्का कर दिया। fest ने 3,500 games का आंकड़ा पार किया, जो साल दर साल 51% ज्यादा है, और बीच वाले title को करीब 200 wishlists और 11 नए followers मिले। ज्यादा games, पतले हिस्से। टॉप 5% को मोटे तौर पर 7,000 wishlists मिलीं, जो एक साल पहले के करीब 10,000 से कम है, यानी जीतने वाले भी अब एक ज्यादा भीड़ भरी पाई बाँट रहे हैं। Co-op का दबदबा बना रहा, और "fest से ठीक पहले अपना demo shadow-drop कर दो" वाला विचार फिर से गलत साबित हुआ: जिन दस सबसे ज्यादा कमाई करने वालों का विश्लेषण किया गया, उनमें से सिर्फ एक ने अपना demo fest से कुछ ही दिन पहले launch किया था। बाकियों के demos एक महीने या उससे ज्यादा समय से बाहर थे। पहले audience बनाओ, हर edition यही एक बात कहता रहता है।

वे genres जो जीतते रहते हैं

फरवरी 2025 के diamond tier से:

• Horror (×2) - Steam को horror पसंद है। हमेशा से रहा है।
• Strategy/Management (×4) - "crafty-buildy-simulationy" वाला माहौल है
• Co-op "friend slop" - Lethal Company ने बाढ़ के दरवाजे खोल दिए
• Point-and-click (×2) - पर दोनों ही मौजूदा audience वाले sequels थे

Point-and-click वाली बात दिलचस्प है। Beholder: Conductor अपनी series की चौथी game थी। Duck Detective एक sequel था। उनके पास पहले से जुड़े हुए audience थे। पहली बार point-and-click बनाने वाले devs को ऐसे नतीजे नहीं दिखते।

छोटी Games क्या कहती हैं

हर कोई diamond tier के पीछे नहीं भाग रहा। छोटे छोर पर मौजूद developers ने अक्टूबर 2025 से जो बताया वो यह है:

"visits से wishlists तक 62% conversion rate। store page खुद तो काम करता दिखता है। पर impressions ज्यादा थे और लोगों ने click नहीं किया। Capsule art को अपडेट की जरूरत है।"

"57% store visitors ने हमारा demo खेला। यह ज्यादा लगता है? पर जिन्होंने खेला उनमें से सिर्फ 15% ने wishlist भी किया। कुछ उम्मीदों पर खरा नहीं उतरा।"

"हमारी game cozy लगी या नहीं यह पूछने के लिए r/cozygames से हमेशा के लिए ban कर दिया गया। हमेशा नियम मानने की कोशिश करता हूँ पर यह काफी हैरान करने वाला था।"

मेहनत असली है। ये developers capsule art टेस्ट कर रहे हैं, tags ट्वीक कर रहे हैं, subreddits से ban हो रहे हैं। यह कोई चमक-धमक वाला काम नहीं है।

एक पैटर्न जो और मजबूत हुआ है: co-op "friend slop" games भारी demo play counts जुटाती हैं पर उन players में से कम को wishlists में बदलती हैं, क्योंकि जो audience आता है वो casual होता है और दोस्तों के साथ मस्ती करने आया होता है, किसी release को ट्रैक करने नहीं। ज्यादा plays का मतलब अपने आप ज्यादा wishlists नहीं होता।

ईमानदार Playbook

Next Fest से महीनों पहले:

1. अपना demo जल्दी launch करो। मतलब, बहुत जल्दी। जीतने वालों के demos 6-12 महीने तक बाहर थे।
2. पहले छोटे genre festivals में हिस्सा लो। उन्हें polish runs की तरह इस्तेमाल करो।
3. 2,000+ wishlists तक बनाओ। यही आपकी असली threshold है।

Next Fest के दौरान:

1. दिन 1-2 ही बनाते या बिगाड़ते हैं। सब कुछ झोंक दो।
2. हो सके तो stream करो। यह आपके page पर "live" दिखता है।
3. streamers के साथ तालमेल बिठाओ। जरूरत पड़े तो उन्हें भुगतान करो।
4. अपने demo को एक अलग Steam page पर रखो ताकि वो reviews जमा कर सके।

Next Fest के बाद:

1. तुरंत launch मत करो। कुछ हफ्ते बाद असल में बेहतर performance देता है।
2. momentum को अपने असली launch marketing के लिए इस्तेमाल करो।

इसे कब छोड़ देना चाहिए

सीधी बात: Next Fest हर किसी के लिए नहीं है।

इसे छोड़ दो अगर:

• आपके पास 1,000 से कम wishlists हैं (दिन 3 तक आप अदृश्य हो जाएँगे)
• आपका demo polished नहीं है (पहली छाप के लिए आपको एक ही मौका मिलता है)
• यह आपका पहला festival ही है (पहले छोटे वाले करो)
• आप उसके तुरंत बाद launch कर रहे हैं (कुछ हफ्ते रुको)

हर महीने दर्जनों छोटे festivals होते हैं। ज्यादा focused audiences। कम competition। सूची के लिए howtomarketagame.com/festivals देखें।

Next Fest डिफ़ॉल्ट है क्योंकि Valve सबको शामिल होने के लिए कहता है। पर सबसे अच्छी marketing वो चीज नहीं है जिसके लिए सबको कहा जाता है।

लेखक के बारे में

Oleg Sidorkin indie game developers के लिए tools बनाते हैं। वे game marketing data और developer postmortems का अध्ययन करते रहे हैं ताकि समझ सकें कि असल में क्या काम करता है बनाम किस चीज का हाइप बनता है।

Game Developer editors के लिए नोट्स:

IMAGE PLACEMENTS:

1. After "Almost exactly 2×" paragraph - Eilean Mor video embed or screenshot
2. After "Do No Harm (February 2025)" header - Do No Harm video embed or screenshot
3. After "Cairn (October 2025)" header - Cairn video embed or screenshot
4. After "YAPYAP (October 2025)" header - YAPYAP video embed or screenshot

VIDEO URLS:

• Eilean Mor: https://www.youtube.com/watch?v=jFv7SjsQEws
• Do No Harm: https://www.youtube.com/watch?v=GBlOHAL1LkY
• Cairn: https://www.youtube.com/watch?v=x6KWhvvk3bM
• YAPYAP: https://www.youtube.com/watch?v=7d8Fd9XXAtQ

STEAM LINKS (for reference/linking):

• Eilean Mor: https://store.steampowered.com/app/3871570/Eilean_Mor_The_Lost_Keepers/
• Do No Harm: https://store.steampowered.com/app/3138780/Do_No_Harm/
• Cairn: https://store.steampowered.com/app/1588550/Cairn/
• YAPYAP: https://store.steampowered.com/app/3834090/YAPYAP/

आख़िरी अपडेट: जुलाई 2026।

Soundtrack कभी game का वह हिस्सा था जिसे अकेले काम करने वाले developers बस छोड़ देते थे। आप या तो खामोशी के साथ game भेजते, या कोई ऐसा free loop उठा लेते जिसे पहले ही पचास games इस्तेमाल कर चुके होते, क्योंकि एक composer रखना बाकी पूरे project से भी महँगा पड़ता था। AI music ने यह गणित बदल दिया। आप एक वाक्य में mood बताइए और एक मिनट से भी कम में पूरा track वापस पाइए।

2026 में मुश्किल हिस्सा quality नहीं है। इनमें से ज़्यादातर tools इतने अच्छे लगते हैं कि सीधे ship किए जा सकें। मुश्किल है licensing। Game एक commercial product है, और लोकप्रिय music generators में से आधे या तो अपने free tier पर commercial use रोक देते हैं या अपने training data को लेकर अनसुलझे मुकदमे ढो रहे हैं। ग़लत वाला चुना, तो आप अपनी game files के अंदर एक कानूनी समस्या ship कर रहे हैं।

इसमें हमारा भी दाँव लगा है। Cinevva का अपना music tool है, और इसके पीछे के engines चुनते समय हमने तीन से कहीं ज़्यादा आज़माए। हम ElevenLabs Music, ACE-Step और Mubert पर टिके, और तय करने वाली बात यह नहीं थी कि किसी blind listening test में कौन जीता। बात यह थी कि जब कोई creator वही एकमात्र अहम सवाल पूछे, तब हम किन licenses के पीछे डटकर खड़े रह सकते हैं: क्या मैं इस track वाला game बेच सकता हूँ? यही सवाल नीचे की हर बात में चलता है।

Prompt-से-track लगभग ऐसा सुनाई देता है, वही flow जो आप tool के अंदर इस्तेमाल करेंगे:

एक छोटा AI-generated clip। एक mood बताइए, उससे मेल खाता track पाइए।

यह गाइड उन AI music generators की तुलना करती है जो games के लिए सचमुच काम करते हैं, इस आधार पर बाँटकर कि आप उन्हें कैसे इस्तेमाल करेंगे: vocals वाले full-song tools, products के लिए बने royalty-free generators, और वे open models जिन्हें आप खुद चला सकते हैं। हर एक के लिए सबसे अहम बात सबसे पहले रखी गई है: क्या आप उसका output ऐसे game में कानूनी रूप से डाल सकते हैं जिसे आप बेचते हैं?

झटपट चुनाव

छोटा जवाब चाहिए, तो यहाँ बताया है कि हर tool किसके लिए है।

Vocals वाले full-song generators

ये वे tools हैं जो एक text prompt से पूरा track लिखते हैं, अक्सर गायन के साथ। जब लोग "AI music" कहते हैं तो ज़्यादातर इन्हीं का मतलब होता है, और जब आपको theme song, menu track, या trailer के लिए vocal piece चाहिए तो यही सही चुनाव हैं।

ElevenLabs Music

अगर आप कोई commercial game ship कर रहे हैं और licensing की चिंता छोड़ना चाहते हैं, तो यहीं से शुरू करें। ElevenLabs ने अगस्त 2025 में Eleven Music लॉन्च किया, और अपने प्रतिद्वंद्वियों से अलग इसने model को licensed production music पर train किया और Merlin तथा Kobalt के साथ सौदे किए ताकि rightsholders को भुगतान मिले। Outputs व्यापक commercial use के लिए स्वीकृत हैं, और terms में gaming का नाम लेकर उल्लेख है।

बदले में कुछ guardrails हैं जिनका आपको पालन करना है। आप इसे असली artist नामों, गीत शीर्षकों या lyrics से prompt नहीं कर सकते, और कुछ क्षेत्र बाहर रखे गए हैं, तो इसके इर्द-गिर्द build करने से पहले music terms पढ़ लें। किसी game soundtrack के लिए ये सीमाएँ शायद ही आड़े आती हैं। बदले में आपको वह चीज़ मिलती है जो 2026 में कोई और vocal generator नहीं दे सकता: licensing की एक साफ़ कड़ी जिसकी ओर आप किसी के पूछने पर इशारा कर सकें। यह हमारे अपने music tool के पीछे के तीन engines में से एक है, ठीक इसीलिए क्योंकि licensing तय है।

Suno

Suno एक पूरे vocal गीत तक पहुँचने का सबसे तेज़ रास्ता है, और v5.5 model (मार्च 2026) तक आते-आते इसके vocals किसी भी generator से ज़्यादा स्वाभाविक हैं। Games के लिए नियम सरल और सख़्त हैं। Free tier non-commercial है, बस इतना ही। आपको महीने के $10 (या सालाना बिलिंग पर $8/माह) वाला Pro plan चाहिए, जो commercial rights और downloadable files, लगभग 500 गानों जितने credits, और v5.5 model तक पहुँच देता है। महीने के $30 वाला Premier plan Suno Studio जोड़ता है, जो games के लिए मायने रखता है क्योंकि यह एक track को stems में अलग करता है जिन्हें आप अलग-अलग in-game संदर्भों में remix कर सकते हैं।

दो बातें साफ़ रखें। पहली, commercial license copyright ownership नहीं है। Suno की अपनी terms कहती हैं कि commercial-use rights देना ownership के हस्तांतरण से अलग है, और US कानून पूर्ण copyright के लिए आमतौर पर एक मानव लेखक माँगता है, तो आपके पास track इस्तेमाल करने का license है, कोई अटूट copyright नहीं। दूसरी, Suno ने नवंबर 2025 में Warner के साथ समझौता किया, पर Sony और Universal के मुकदमे जुलाई 2026 की summary-judgment सुनवाई तक भी सक्रिय थे। Suno ने यह भी कहा है कि वह 2026 में बाद में अपने मौजूदा models को label-licensed नए models से बदलने की योजना रखता है, तो ठीक कौन-सा model और download नियम आपके पैरों तले बदल सकते हैं। किसी अदालत ने अब तक downstream users को ज़िम्मेदार नहीं ठहराया, और किसी indie के लिए व्यावहारिक जोखिम कम है, पर यह एक tail जोखिम है जिसे किसी franchise की नींव इस पर रखने से पहले जान लेना चाहिए। अपनी भुगतान रसीदें सबूत के तौर पर रखें कि हर track बनाते समय आप subscribed थे।

Udio

Udio शानदार audio बनाता है, और 2026 में आप उसे game में नहीं डाल सकते। अक्टूबर 2025 में Universal Music के साथ समझौते के बाद इसने सारे downloads और stems बंद कर दिए और एक सिर्फ़-streaming वाला दीवारों से घिरा बाग़ बन गया। आप app के अंदर बना, सुन और remix कर सकते हैं, पर कोई file export नहीं कर सकते। Game development के लिए यह अयोग्य ठहराने वाली बात है, क्योंकि पूरा मक़सद ही एक audio file को आपके engine में लाना है। Universal 2026 के लिए एक licensed Udio platform साथ मिलकर बना रहा है, तो यह बदल सकता है, पर अभी के लिए Udio को soundtrack जुटाने की जगह नहीं, खेलने की जगह मानें।

Products के लिए बने royalty-free generators

यह समूह musicians के बजाय creators और कंपनियों को लक्ष्य करता है। Tracks आमतौर पर instrumental होते हैं, interfaces सरल होते हैं, और पेशकश है licensing की सुरक्षा। कई एक API देते हैं, जो वह रास्ता है अगर आप चाहते हैं कि players आपके game के अंदर अपना music खुद बनाएँ।

Mubert

Mubert products के लिए बना है, और games इसके मुख्य उपयोगों में से एक हैं। यह prompt, mood, BPM या activity के हिसाब से royalty-free, DMCA-free music बनाता है, licensed और partner content पर trained है। अहम बारीकी है plan की संरचना, क्योंकि यही तय करती है कि आप कानूनी रूप से क्या कर सकते हैं। Startup plan पर music आपके app के अंदर बजता है पर users उसे export नहीं कर सकते, जो background music वाले mobile game के लिए ठीक बैठता है। अगर आप चाहते हैं कि players अपने बनाए tracks export या share करें, तो आपको Startup+ या उससे ऊपर चाहिए, जो sublicensing जोड़ता है। Free tier non-commercial है। Mubert भी हमारे music tool के पीछे के engines में से एक है, इसीलिए app के अंदर generate करना बाद में जोड़ी गई चीज़ नहीं बल्कि पहली-दर्जे का रास्ता है।

Soundraw

Soundraw royalty-free generators का पुराना खिलाड़ी है, copyright सवाल को किनारे करने के लिए पूरी तरह अपने ही licensed catalog पर trained। आप genre, mood और theme चुनते हैं, फिर arrangement को महीन करते हैं। यह व्यक्तिगत उपयोग के लिए subscription है, लगभग $17/माह, और यह एक API देता है जिसे वे game developers और creator tools इस्तेमाल करते हैं जो generation embed करना चाहते हैं। जब आपको instrumental background music और एक ऐसी licensing कहानी चाहिए जिसे आप publisher को समझा सकें, तब यह एक सुरक्षित, बिना तड़क-भड़क वाला चुनाव है।

Beatoven, Loudly और AIVA

खास ज़रूरतों के लिए जानने लायक तीन और। Beatoven.ai किफ़ायती विकल्प है, commercial rights सहित लगभग $2.50/माह, जिसे हराना मुश्किल है अगर आपको बस साफ़ background music चाहिए। Loudly थोड़ा ऊपर है, लगभग $6/माह, और customization तथा collaboration controls पर ज़ोर देता है। AIVA विशेषज्ञ है: यह cinematic और orchestral scoring के लिए बना है, तो जब आपके game को pop loop नहीं बल्कि एक भव्य symphonic theme चाहिए तो यही वह है जिसकी ओर हाथ बढ़ाएँ। तीनों अपने paid tiers पर commercial rights देते हैं और free पर रोकते हैं, जो इस पूरी श्रेणी में एक जैसा pattern है।

वे open models जिन्हें आप खुद चला सकते हैं

अगर आप कोई subscription नहीं, कोई per-track fee नहीं, और unreleased project audio पर पूरा नियंत्रण चाहते हैं, तो model को अपने hardware पर चलाइए। Open audio models तेज़ी से बराबरी पर आ गए, और 2026 तक कई सचमुच अच्छे हैं। एक ही नियम: weights का license देखिए, सिर्फ़ code का नहीं, क्योंकि वे अक्सर अलग होते हैं।

Stable Audio 3

Stable Audio 3 (मई 2026) games के लिए सबसे मज़बूत open विकल्प है, और वजह है licensing के साथ पहुँच। Stability ने पूरी तरह licensed data पर trained तीन open-weight models जारी किए: Small-Music और Small-SFX दोनों CPU पर चलते हैं, GPU की ज़रूरत नहीं, और Medium ऊँची quality के लिए एक consumer GPU पर चलता है। सिर्फ़ Large model API-only है। Stability AI Community License के तहत आप अपने outputs के मालिक हैं और उन्हें आज़ादी से commercialize कर सकते हैं, जब तक आपका studio सालाना $1M revenue पार न कर ले, जिस बिंदु पर आप एक Enterprise license पर चले जाते हैं जो कानूनी indemnification भी जोड़ती है।

Games के लिए यह एक साथ दो ज़रूरतें पूरी करता है। Music models लगभग छह मिनट तक की परिवर्तनशील-लंबाई वाले tracks बनाते हैं, और Small-SFX वह सबसे अच्छा open model है जिसके sound effects आप सचमुच ship कर सकते हैं। आप इनमें से किसी को भी अपने ही audio के एक folder पर LoRA fine-tune कर सकते हैं, यही वह तरीका है जिससे आप इसे अपने game की ध्वनि-शैली सिखाते हैं, फिर मेल खाते menu loops, combat stingers और ambience बनाते हैं जो सब एक ही score जैसे लगते हैं।

ACE-Step

ACE-Step vocals वाले full tracks के लिए जानने लायक open model है। 1.5 line (जनवरी 2026) MIT-licensed है, जो जितना उदार हो सकता है उतना है, और यह 19 भाषाओं में कई मिनट का music तेज़ी से बनाता है, जिसमें voice cloning, remixing और lyric editing अंदर से मौजूद हैं। जो teams pipeline किराए पर लेने के बजाय उसके मालिक होना चाहती हैं, उनके लिए यह Suno का self-hosted जवाब है, और हमारे music tool के पीछे का तीसरा engine है।

बाक़ी open मैदान

ज़रूरत के हिसाब से कुछ और। YuE (Apache 2.0) एक lyric sheet से vocals वाले पूरे गीत बनाता है और यह अच्छी तरह करने वाला पहला open model था। DiffRhythm 2 (Apache 2.0, फ़रवरी 2026) तेज़ full-song generation के लिए बना है। Meta का MusicGen prototyping के लिए अब भी ठीक चलता है, पर उसके weights CC-BY-NC हैं, तो यह सिर्फ़ एक sketch tool है। किसी ऐसे game में जिसे आप बेचते हैं, MusicGen track कभी ship न करें। अंतिम संस्करण के लिए ACE-Step या Stable Audio पर चले जाएँ।

Google का Magenta RealTime (code Apache 2.0, weights CC-BY) अलग किस्म का है, और games के लिए सबसे अच्छे तरीके से अलग है। एक तैयार file render करने के बजाय, यह बजते हुए music को live बनाता है जिसे आप बजते-बजते steer करते हैं। यह ठीक उसी आकार का है जैसा एक adaptive soundtrack होता है जो player के combat में घुसने या किसी boss के आने पर बदल जाता है। कोई और open model real-time steering के लिए नहीं बना, तो अगर interactive music आपका लक्ष्य है, तो शुरुआत यहीं से है।

सिर्फ़ music नहीं, sound effects भी

Soundtrack काम का आधा हिस्सा है। Games को footsteps, UI clicks, धमाके और ambience भी चाहिए, और वही AI-licensing नियम लागू होते हैं। दो विकल्प उभरकर सामने आते हैं। Stable Audio 3 Small-SFX locally चलता है, माँग पर effects बनाता है, और अपने music भाई-बहनों जैसी ही commercial-safe Community License के तहत आता है। ElevenLabs के पास एक समर्पित sound-effects generator है जिसकी commercial-के-लिए-स्वीकृत मुद्रा Eleven Music जैसी ही है, इसीलिए हमारा अपना SFX tool music वाले के साथ-साथ मौजूद है। पारंपरिक रास्ते के लिए, हमारी free sound effects और music गाइड उन CC0 libraries को समेटती है जिन्हें अपनी जेब में रखना अच्छा है।

Games के लिए licensing की हक़ीक़त

यह वह हिस्सा है जो आपको takedown notice से बचाता है, तो जो कुछ भी आप ship करने की सोच रहे हैं उसे generate करने से पहले इसे पढ़ें।

"Royalty-free" का मतलब "copyright-free" नहीं, और न ही ownership। Royalty-free का मतलब है कि track के हर बार बजने पर आप fee नहीं देते। यह इस बारे में कुछ नहीं कहता कि music का मालिक कौन है या training data साफ़ था या नहीं। तीन अलग concepts, marketing copy में अक्सर घालमेल कर दिए जाते हैं।

Commercial game के लिए free tiers लगभग कभी सुरक्षित नहीं होते। Suno, Mubert, Soundraw, Beatoven और Loudly सभी में free plan व्यक्तिगत और non-commercial है। एक game जिसे आप बेचते हैं, या ads या paid DLC वाला एक free game भी, एक commercial project है। एक paid plan या उदार रूप से licensed open model इस्तेमाल करें, और free-tier track ship न करें।

Training-data मुकदमों पर नज़र रखें। Suno और Udio दोनों बड़े labels के सक्रिय मुकदमे झेल रहे हैं। अब तक किसी अदालत ने किसी downstream user को ज़िम्मेदार नहीं ठहराया, और किसी indie का व्यावहारिक जोखिम कम है, पर यह असली है, और यही वजह है कि 2026 में सबसे साफ़ चुनाव वे tools हैं जो licensed data पर trained हैं: ElevenLabs Music, Stable Audio, Mubert, Soundraw और AIVA।

अपनी रसीदें रखें। Suno जैसे tools पर commercial rights उन tracks पर लागू होते हैं जो आपने subscribed रहते हुए बनाए। generation के समय subscription के सक्रिय होने का सबूत सहेजें, ताकि आप दिखा सकें कि बनाते समय track licensed था।

जहाँ platform माँगे वहाँ disclose करें। itch.io और Steam के अपने AI-content disclosure नियम हैं, और यहाँ ईमानदारी एक सस्ता बीमा है। हम disclosure को कैसे संभालते हैं इसके लिए हमारी AI-generated content policy देखें, और music licensing आपकी art और code के साथ कैसे बैठती है इसके लिए हमारी game asset licenses guide देखें।

सिर्फ़ एक track नहीं, game में फ़िट होने वाला music बनाना

तीन मिनट का pop गीत game soundtrack नहीं है। Games को ऐसे loops चाहिए जिनमें सुनाई देने वाला जोड़ न हो, ऐसे stems जिन्हें दृश्य बदलते ही आप mix कर सकें, और ऐसे mood transitions जो player के साथ चलें। कुछ workflow नोट।

Loops के लिए, थोड़ा लंबा टुकड़ा generate करें और उसे एक साफ़ loop बिंदु पर काटें, या continuation और inpainting feature (Stable Audio और Suno दोनों में एक है) से अंत को शुरुआत से वापस जोड़ें। Stems के लिए, Premier plan पर Suno Studio और ACE-Step का remix mode दोनों एक track को हिस्सों में बाँटते हैं, तो आप किसी stealth हिस्से में drums हटा सकते हैं और किसी पीछा-दृश्य के लिए वापस ला सकते हैं। player के काम पर प्रतिक्रिया देने वाले adaptive, real-time music के लिए Magenta RealTime खासतौर पर बना है, और Mubert की mood के हिसाब से अंतहीन streams किसी app के अंदर ambient या अनंत background layers के लिए अच्छी चलती हैं।

मैं असल में क्या इस्तेमाल करूँगा

अगर आज मुझे किसी game को score करना हो, तो जिस stack की ओर मैं हाथ बढ़ाऊँगा वह यह है।

ऐसा commercial game ship कर रहे हैं जहाँ licensing कसी हुई होनी चाहिए? Vocal और lead tracks के लिए ElevenLabs Music, और instrumental beds तथा sound effects के लिए Stable Audio 3 इस्तेमाल करें। दोनों licensed data पर train होते हैं और अपने outputs को commercial use के लिए स्वीकृत करते हैं, ठीक इसीलिए हमारे अपने tool के तीन engines में से दो इसी खाने से आते हैं।

तेज़ iteration और सबसे अच्छे vocals चाहिए? जवाब है Suno Pro, बशर्ते आप अपनी रसीदें रखें और छोटे मुकदमे-tail जोखिम को स्वीकारें। बेहतरीन को Suno Studio में ले जाकर stems निकालें।

पूरा नियंत्रण और कोई subscription नहीं चाहते? Vocal tracks के लिए ACE-Step और instrumentals तथा SFX के लिए Stable Audio 3 self-host करें, फिर अपने ही audio पर Stable Audio को LoRA fine-tune करें ताकि सब कुछ एक ही score जैसा लगे।

अपने app के अंदर background music के लिए, या players को अपना खुद बनाने देने के लिए, उस plan tier पर Mubert या Soundraw API जोड़ें जो इस बात से मेल खाए कि users export कर सकते हैं या नहीं। और अगर आप gameplay पर प्रतिक्रिया देने वाला adaptive score चाहते हैं, तो Magenta RealTime से prototyping शुरू करें।

आम ग़लती है हर चीज़ के लिए एक ही tool की ओर हाथ बढ़ाना। Music, stems, SFX और adaptive layers अलग-अलग काम हैं, और सही जवाब आमतौर पर दो या तीन tools हैं जो हर एक कोई एक काम अच्छा करता है। इन सबका मक़सद एक ही है: soundtrack का वह कोना न रहना जिसे आप काट देते हैं।

आम सवाल

Commercial game के लिए सबसे अच्छा AI music generator कौन-सा है?

साफ़ licensing के लिए, ElevenLabs Music और Stable Audio 3 2026 में आगे हैं क्योंकि दोनों licensed data पर train होते हैं और अपने outputs को commercial use के लिए स्वीकृत करते हैं। सबसे अच्छे vocals तेज़ी से चाहिए, तो Suno Pro चलता है अगर आप जारी Sony मुकदमे को एक छोटे tail जोखिम के रूप में स्वीकारें। जो कुछ भी आप ship करें उसके लिए free tiers और non-commercial weights से बचें।

क्या मैं किसी ऐसे game में AI-generated music कानूनी रूप से इस्तेमाल कर सकता हूँ जिसे मैं बेचता हूँ?

आमतौर पर हाँ, किसी paid plan या उदार रूप से licensed open model पर, पर बारीकियाँ मायने रखती हैं। Free tiers लगभग हमेशा non-commercial होते हैं, एक commercial license copyright के मालिक होने जैसा नहीं है, और बिना license वाले data पर trained tools मुकदमे का जोखिम ढोते हैं। खास license जाँचें, अपने subscription का सबूत रखें, और जहाँ आपका platform माँगे वहाँ AI content disclose करें।

कौन-से AI music generators मैं अपने hardware पर चला सकता हूँ?

Stable Audio 3 (Small models CPU पर, Medium एक consumer GPU पर), ACE-Step, YuE, DiffRhythm 2 और Magenta RealTime सभी open और self-hostable हैं। code का नहीं, weights का license जाँचें: MusicGen के weights non-commercial हैं, जबकि ACE-Step (MIT) और Stable Audio (Community License) commercial use की अनुमति देते हैं।

Game के लिए looping या adaptive music कैसे पाऊँ?

एक लंबा track generate करें और एक बिना-जोड़ वाले loop पर काटें, या continuation और inpainting से दोनों सिरे जोड़ें। Stems के लिए Suno Studio या ACE-Step का remix mode इस्तेमाल करें। gameplay पर प्रतिक्रिया देने वाले real-time music के लिए Magenta RealTime live steering के लिए बना है, और Mubert की mood-आधारित streams अंतहीन background layers के लिए ठीक बैठती हैं।

और पढ़ें

• Games के लिए सबसे बेहतरीन ओपन-सोर्स जनरेटिव AI मॉडल, video, image, 3D, audio और voice का पूरा open model ब्योरा
• Games के लिए सबसे बेहतरीन AI Asset Generators, 3D models, textures और audio generation एक साथ
• Games के लिए मुफ़्त Sound Effects और Music, AI generation के साथ जोड़ने लायक CC0 libraries
• Game Asset Licenses की व्याख्या, music licensing आपकी art और code के साथ कैसे बैठती है
• AI-generated content policy, हम AI disclosure को कैसे संभालते हैं

आखिरी अपडेट: जून 2026.

2026 की कैज़ुअल गेम्स की कहानी "बूम जारी है" नहीं है। यह है कि "बूम परिपक्व हो गया।" खिलाड़ी अब भी इन गेम्स को ज़्यादा बार खोल रहे हैं, लेकिन नए गेम कम इंस्टॉल कर रहे हैं, और पैसा ऐसे तरीकों से घूम रहा है जो तीन साल पहले जीतने वाले गेम से अलग तरह के गेम को इनाम देते हैं। हमने Sensor Tower, AppMagic (Gamesforum Intelligence और GameRefinery के ज़रिये) के पूरे साल 2025 के आँकड़े खंगाले, और Deconstructor of Fun व PocketGamer.biz के विश्लेषकों को पढ़ा, ताकि असली बदलावों को हाइप से अलग किया जा सके। असल में यह हो रहा है।

छोटी बात यह है: 2025 में कैज़ुअल गेम्स का बाज़ार परिपक्व हो गया। इन-ऐप रेवेन्यू सिर्फ़ 1.3% बढ़कर लगभग $81.75 बिलियन हुआ जबकि डाउनलोड 7.2% गिरकर 50.4 बिलियन रह गए, यानी अब ग्रोथ खिलाड़ियों के ज़्यादा खर्च करने से आती है, नए इंस्टॉल से नहीं। इन-ऐप रेवेन्यू बढ़ाने वाला इकलौता सेगमेंट hybrid-casual रहा, जो 20% बढ़कर $4.2 बिलियन हुआ, जिसमें hybrid-casual puzzle सबसे आगे रहा। मॉनेटाइज़ेशन एक विस्तृत दायरे में फैल गया, केवल-ऐड वाले वॉल्यूम गेम से लेकर $500 मिलियन से ज़्यादा कमाने वाले बिना-ऐड गेम तक, और generative AI स्टूडियो में प्रयोग से हटकर मानक टूलिंग बन गया।

बाज़ार ने इंस्टॉल के दम पर बढ़ना बंद कर दिया

पूरे साल 2025 के आँकड़ों के मुताबिक, मोबाइल गेम्स ने 2025 में इन-ऐप परचेज़ से लगभग $81.75 बिलियन कमाए, लेकिन यह 2024 के मुकाबले सिर्फ़ 1.3% की बढ़त थी। डाउनलोड उल्टी दिशा में गए और 7.2% गिरकर 50.4 बिलियन रह गए, लगातार दूसरे साल इनमें गिरावट आई है। तुलना के लिए, स्टोर भर में सभी ऐप्स का इन-ऐप खर्च ठीक-ठाक 10.6% बढ़कर $167 बिलियन हुआ, तो सपाट होने वाला मामला खास तौर पर गेम्स का है, आम तौर पर मोबाइल कॉमर्स का नहीं।

यही फ़र्क पूरी कहानी है। एंगेजमेंट अब भी चढ़ रहा है (पिछले साल sessions 12% और बिताया गया समय 7.9% बढ़ा), लेकिन नए इंस्टॉल घट रहे हैं। ग्रोथ अब उन खिलाड़ियों से ज़्यादा पैसा निकालने से आती है जो पहले से आपके पास हैं, नए हासिल करने से नहीं। सस्ते user-acquisition का दौर खत्म हो चुका है।

यही विभाजन आप कैज़ुअल कैटेगरी के भीतर भी देख सकते हैं। Gamesforum Intelligence की कैज़ुअल रिपोर्ट (AppMagic डेटा) के अनुसार, टॉप 1,000 कैज़ुअल गेम्स में इन-ऐप परचेज़ रेवेन्यू 2022 के $17.47 बिलियन से बढ़कर 2024 में $21.99 बिलियन हुआ, और 2025 के लिए $22.99 बिलियन का अनुमान है, जबकि डाउनलोड करीब 16 बिलियन के आसपास लगभग सपाट रहे। ज़्यादा रेवेन्यू, उतने ही डाउनलोड। खिलाड़ी बस हर इंस्टॉल पर ज़्यादा खर्च कर रहे हैं।

hypercasual का केवल-ऐड मॉडल टूट गया, और यह ठीक है

जो हेडलाइन आपको बार-बार दिखेगी वह है "hypercasual मर रहा है।" यह आधा सच है। जो टूटा वह इकोनॉमिक्स है, गेम नहीं। सालों तक hypercasual एक ही तरकीब पर चला: इंस्टॉल सस्ते में खरीदो, ऐड दिखाओ, फर्क अपने पास रखो। जैसे-जैसे acquisition की लागत उससे ऊपर चढ़ी जितना ऐड वापस चुका सकते थे, वह शुद्ध केवल-ऐड मॉडल काम करना बंद कर गया।

गेम खुद ठीक चल रहे हैं। Game World Observer के अनुसार, hypercasual ने 2025 में 22.05 बिलियन इंस्टॉल के साथ डाउनलोड पर दबदबा बनाए रखा और बिताया गया समय बढ़ाता रहा। PocketGamer.biz बताता है कि अग्रणी टाइटल पिछले साल के मुकाबले हर महीने करीब 3 गुना ज़्यादा कमा रहे थे, हालाँकि वह आँकड़ा एक कम बेस से आता है और आंशिक रूप से उन hybrid-casual गेम्स को दर्शाता है जिन्हें फिर से वर्गीकृत किया गया। निचोड़ सीधा है: यह फॉर्मैट सिर्फ़ ऐड के दम पर जीने के बजाय ऐड के ऊपर इन-ऐप परचेज़ जोड़कर टिकता है।

असली विजेता hybrid-casual है

अगर एक ट्रेंड 2026 को परिभाषित करता है, तो वह hybrid-casual है। Game World Observer के विश्लेषण के अनुसार, पिछले साल इन-ऐप परचेज़ रेवेन्यू बढ़ाने वाला इकलौता कैज़ुअल सेगमेंट यही था, जो 20% बढ़कर $4.2 बिलियन हुआ, जिसमें टॉप 10 टाइटल ने साल-दर-साल 67% से 100% के बीच IAP ग्रोथ दर्ज की। hybrid-casual, hypercasual के छोटे-छोटे, ऐड-फ्रेंडली लूप लेता है और उन पर एक असली कैज़ुअल गेम की meta-progression और खर्च की गहराई जोड़ देता है। यह आसान इंस्टॉल बनाए रखता है और भुगतान करने की एक वजह जोड़ देता है।

ग्रोथ hybrid-casual puzzle में केंद्रित है। GameRefinery की दिसंबर 2025 समीक्षा Match3 जैसे स्थापित सबजॉनर को "बुरी तरह संतृप्त" बताती है, जबकि नए puzzle टाइटल का एक समूह टॉप ग्रॉसिंग चार्ट में चढ़ गया: Color Block Jam, Pixel Flow, Screwdom, Magic Sort, और All in Hole। अकेले Color Block Jam ने एक ही तिमाही में 21.8 मिलियन इंस्टॉल पर करीब $42 मिलियन रेवेन्यू किया। अगर आप तय कर रहे हैं कि 2026 में किस तरह का कैज़ुअल गेम बनाना है, तो "संतृप्त Match3 क्लोन" और "ताज़ा hybrid-casual puzzle" बहुत अलग दाँव हैं।

मॉनेटाइज़ेशन अब एक स्पेक्ट्रम है, कोई एक मॉडल नहीं

अब कोई एक "कैज़ुअल मॉनेटाइज़ेशन मॉडल" नहीं रहा। बाज़ार एक साफ़ स्पेक्ट्रम में बँट गया, और एक गेम कहाँ बैठता है यह इस पर निर्भर करता है कि वह है क्या। तमाम ट्रैकर से एक जैसा पढ़ने को मिलता है कि इन-ऐप परचेज़ को ऐड के साथ मिलाना बीच की सबसे कारगर रणनीति बन गया है, लेकिन छोर अब भी बड़ा कमाते हैं।

सबक "एक चुनो" नहीं है। बात यह है कि मॉडल को गेम के पीछे चलना चाहिए। बड़ी पहुँच वाला एक शुद्ध puzzle खिलौना ऐड के दम पर जी सकता है। कलेक्शन, प्रोग्रेशन और सोशल हुक वाला गेम अगर अपने खर्च करने वालों को ऐड दिखाता है तो पैसा टेबल पर छोड़ देता है। बीच का लगभग सब कुछ दोनों को मिलाकर सबसे अच्छा करता है। यहाँ के आँकड़े Gamesforum Intelligence की कैज़ुअल रिपोर्ट (AppMagic डेटा) से आते हैं।

पैसा कहाँ घूम रहा है

भौगोलिक रूप से, कैज़ुअल गेम्स ने पश्चिमी बाज़ारों में सबसे बड़ी ग्रोथ दी। उत्तरी अमेरिका में सबसे ज़्यादा निरपेक्ष ग्रोथ दिखी और यूरोप प्रतिशत के हिसाब से तेज़ बढ़ा, जबकि एशिया इकलौता क्षेत्र था जहाँ इन-ऐप परचेज़ रेवेन्यू असल में घटा। एशिया की उस गिरावट का कुछ हिस्सा मज़बूत डॉलर का असर है, लेकिन दिशा साफ़ है: पश्चिम वह जगह है जहाँ कैज़ुअल खर्च बढ़ रहा है।

2025 का सबसे उल्लेखनीय मील का पत्थर गेम्स के ठीक बाहर बैठता है। पहली बार, गैर-गेम ऐप्स ने मोबाइल इन-ऐप परचेज़ में गेम्स से ज़्यादा कमाया, करीब $85.6 बिलियन बनाम $81.8 बिलियन, और उस बदलाव का एक बड़ा हिस्सा generative-AI सब्सक्रिप्शन ऐप्स से आया, जैसा Deconstructor of Fun बताता है। गेम्स ने उसी स्टोर पर टॉप जगह गँवा दी जो कभी उनकी हुआ करती थी, कुछ हद तक AI प्रोडक्ट्स के हाथों। इस पर ठहरकर सोचना ज़रूरी है।

कैज़ुअल गेम कैसे बनते हैं, इसमें AI क्या बदल रहा है

AI समीकरण के दोनों तरफ़ नज़र आता है। खर्च की तरफ़, जैसा ऊपर बताया, AI ऐप्स अब वह पैसा खींच रहे हैं जो पहले गेम्स की ओर जाता था। प्रोडक्शन की तरफ़, generative AI प्रयोग से हटकर मानक टूलिंग बन गया है। GDC के लंबे समय से चल रहे State of the Game Industry सर्वे में पाया गया कि 52% डेवलपर ऐसी कंपनियों में काम करते हैं जो org में कहीं न कहीं generative AI इस्तेमाल करती हैं, और 36% इन टूल्स को अपने काम में इस्तेमाल करते हैं।

हालाँकि यह सीधी ऊपर जाती रेखा नहीं है। एक और हालिया Game Developer Collective सर्वे में पाया गया कि व्यक्तिगत इस्तेमाल घटकर 29% रह गया, जो बताता है कि कुछ टीमों ने AI टूलिंग आज़माई और पीछे हट गईं। 2026 में ईमानदार पढ़ाई यह है कि AI गेम स्टूडियो में पक्के तौर पर मुख्यधारा में है लेकिन अब भी यह तय कर रहा है कि कहाँ यह सचमुच मदद करता है, जो कैज़ुअल गेम्स के लिए मतलब है तेज़ prototyping, asset generation, और live-ops कंटेंट, न कि बिना छुए पूरा गेम शिप करना।

एकल और छोटे क्रिएटर्स के लिए, यही सबसे दिलचस्प मोर्चा है। जिस prompt-to-game तरीके ने AI-ऐप कैटेगरी बनाई, वही अब खुद गेम बनाने पर लक्षित है। कैज़ुअल वह जॉनर है जिसे AI सबसे अच्छे से संभालता है, क्योंकि लूप कसे हुए हैं और स्कोप छोटा है, और ठीक इसीलिए Cinevva जैसा टूल एक वाक्य लेकर आपको आपके browser में एक खेलने लायक गेम थमा सकता है।

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

इसे जोड़कर देखें तो 2026 की रणनीति 2022 से अलग है। अब आप सस्ते इंस्टॉल जीतने की दौड़ में नहीं हैं, क्योंकि वह खेल खत्म हो चुका है। आप कुछ ऐसा बनाने की कोशिश कर रहे हैं जिसे एक छोटा दर्शक-वर्ग सच में बनाए रखे और उस पर खर्च करे। यह उस साफ़ हुक का पक्ष लेता है जिसके नीचे गहराई हो, ऐसे hybrid मॉनेटाइज़ेशन का जो ऐड देखने वालों और खर्च करने वालों दोनों का सम्मान करे, और किसी सिद्ध लूप पर एक ताज़ा नज़रिये का, न कि हज़ारवें Match3 क्लोन का। पश्चिमी दर्शक खर्च कर रहे हैं, puzzle टॉप पर भीड़भाड़ वाला है पर नई mechanics के लिए खुला है, और एक आइडिया आज़माने की लागत अब गिर चुकी है क्योंकि AI आपके लिए पहला खेलने लायक वर्ज़न बना सकता है।

वह आखिरी बात ही असली मौका है। जब एक prototype बनाने में एक weekend के बजाय मिनट लगते हैं, तो आप उतनी ही मेहनत में दस hybrid-casual हुक टेस्ट कर सकते हैं जितनी में पहले एक होता था। बाज़ार उस आइडिया को इनाम देता है जो टिकता है, और उसे ढूँढने का सबसे तेज़ तरीका है बनाना और खेलना, योजना बनाना नहीं। एक prompt से एक शुरू करें और देखें क्या टिकता है।

आम सवाल

क्या 2026 में कैज़ुअल गेम्स का बाज़ार सिकुड़ रहा है?

नहीं, लेकिन डाउनलोड के दम पर बढ़ना बंद हो गया। 2025 में इन-ऐप रेवेन्यू फिर भी थोड़ा बढ़कर करीब $81.75 बिलियन हुआ, जबकि डाउनलोड 7.2% गिरे। बाज़ार परिपक्व हो रहा है, इसलिए ग्रोथ खिलाड़ियों के ज़्यादा खर्च करने से आती है, नए इंस्टॉल से नहीं।

hybrid-casual क्या है और यह मायने क्यों रखता है?

hybrid-casual, hypercasual के आसान, ऐड-फ्रेंडली लूप को एक पूरे कैज़ुअल गेम की गहरी प्रोग्रेशन और परचेज़ के साथ मिला देता है। 2025 में इन-ऐप रेवेन्यू बढ़ाने वाला यह इकलौता कैज़ुअल सेगमेंट था, जो 20% बढ़कर $4.2 बिलियन हुआ, जो इसे अभी अध्ययन करने लायक कैटेगरी बनाता है।

अभी कौन से कैज़ुअल गेम आगे निकल रहे हैं?

नए-हिट की तरफ़, Color Block Jam, Pixel Flow, Screwdom, और Magic Sort जैसे hybrid-casual puzzle टाइटल 2025 में तेज़ी से बढ़े। स्थापित दिग्गजों में, Royal Match और Monopoly Go! रेवेन्यू पर आगे हैं, और Block Blast! डाउनलोड पर आगे है।

मेरे गेम में ऐड इस्तेमाल करूँ या इन-ऐप परचेज़?

यह गेम पर निर्भर करता है। बड़ी पहुँच वाले खिलौने ऐड के दम पर जी सकते हैं, गहरे meta-games बिना-ऐड परचेज़ पर सबसे अच्छा करते हैं, और बीच का लगभग सब कुछ दोनों को मिलाकर ज़्यादा कमाता है। मॉडल को डिज़ाइन के पीछे चलना चाहिए, उल्टा नहीं।

AI कैज़ुअल गेम डेवलपमेंट को कैसे बदल रहा है?

Generative AI अब स्टूडियो में मानक है, 52% डेवलपर ऐसी कंपनियों में हैं जो इसे इस्तेमाल करती हैं। खास तौर पर कैज़ुअल गेम्स के लिए यह prototyping, asset creation, और live-ops को तेज़ करता है, और prompt-to-game टूल अब क्रिएटर्स को एक विवरण से एक खेलने लायक कैज़ुअल गेम बनाने देते हैं।

2026 में कैज़ुअल गेम्स का बाज़ार कितना बड़ा है?

मोबाइल गेम्स ने 2025 में इन-ऐप परचेज़ से करीब $81.75 बिलियन कमाए, 2024 के मुकाबले सिर्फ़ 1.3% ज़्यादा, और टॉप 1,000 कैज़ुअल गेम्स उसमें से करीब $23 बिलियन बनाते हैं। डाउनलोड 7.2% गिरकर 50.4 बिलियन रहे, तो बाज़ार नए इंस्टॉल के बजाय हर खिलाड़ी के खर्च पर बढ़ रहा है।

क्या 2026 में hypercasual मर चुका है?

नहीं। जो टूटा वह केवल-ऐड वाला बिज़नेस मॉडल है, गेम नहीं। hypercasual ने 2025 में 22.05 बिलियन इंस्टॉल के साथ सभी डाउनलोड में सबसे आगे रहा, और यह फॉर्मैट hybrid मॉनेटाइज़ेशन की ओर बढ़ रहा है जो ऐड के ऊपर इन-ऐप परचेज़ जोड़ता है।

संबंधित

• 2026 में सबसे अच्छे AI गेम जेनरेटर — वे टूल जो एक prompt से कैज़ुअल गेम बनाते हैं
• AI से गेम कैसे बनाएँ (बिना कोडिंग) — कदम-दर-कदम बिल्ड
• Vibe Coding गेम्स: यह क्या है और कैसे शुरू करें — वह prototyping सोच जिसे यह बाज़ार इनाम देता है
• AI गेम प्रॉम्प्ट जो आप एक क्लिक में बना सकते हैं — तेज़ी से टेस्ट करने लायक कैज़ुअल हुक
• itch.io पर ज़्यादा प्लेज़ कैसे पाएँ — वह दर्शक-वर्ग ढूँढना जो टिका रहे

आप जो चाहते हैं वो टाइप करते हैं, Cinevva आपके browser में एक खेलने लायक गेम बना देता है, फिर आप chat करके उसे बदलते हैं। यही पूरा लूप है। मुश्किल हिस्सा tool नहीं है, बल्कि यह जानना है कि क्या कहना है।

हमने एक हफ्ते के असली sessions पढ़े ताकि यह देख सकें कि ऐसे prompt में क्या फर्क होता है जो एक ऐसे गेम में बदल जाता है जिसे कोई रखता है, और ऐसे prompt में जिसे पहले build के तुरंत बाद छोड़ दिया जाता है। पैटर्न साफ था, और इसमें कुछ भी पेचीदा नहीं है। यहां वो है जो काम करता है।

एक साफ वाक्य से शुरू करें

सबसे अच्छी शुरुआत एक या दो वाक्य होते हैं जो गेम का प्रकार और वो एक चीज़ बताते हैं जो उसे मज़ेदार बनाती है। "एक top-down zombie survival जहां आप एक फ्लैशलाइट और सीमित गोला-बारूद लेकर चलते हैं" AI को एक genre, एक कैमरा एंगल, एक मुख्य तनाव, और बनाने के लिए एक बंदिश देता है। उसे ठीक-ठीक पता होता है कि क्या बनाना है।

अब इसकी तुलना "platformer" या "shooter games" से करें। ये असली शुरुआतें हैं जो हम रोज़ देखते हैं। Cinevva इनसे कुछ न कुछ बना देगा, पर यह किस्मत की बात है कि वो वही होगा या नहीं जो आपके दिमाग में था। आपकी पहली लाइन जितनी खास होगी, पहला build उतना ही आपकी चाहत के करीब उतरेगा।

अहसास बताएं, किसी मशहूर गेम का नाम नहीं

बहुत से लोग किसी एक टाइटल से शुरू करते हैं। Pokemon। GTA। Minecraft। कोई Roblox गेम जो उन्हें पसंद है। हम समझते हैं, यही वो गेम हैं जिन्होंने आपको एक गेम बनाने की चाहत दी। पेच यह है कि उन्हें बनाने में पूरे स्टूडियो को सालों लगे, और वे एक browser tab में फिट नहीं होते।

तो इसके बजाय उन हिस्सों का नाम लें जो आप वाकई चाहते हैं। अगर आप GTA कहते हैं, तो शायद आपका मतलब है "एक खुले शहर में गाड़ी चलाना और मिशन लेना"। अगर आप Minecraft कहते हैं, तो शायद आपका मतलब है "चीज़ें बनाने के लिए एक अंतहीन ग्रिड पर ब्लॉक रखना और तोड़ना"। mechanic को साफ बताएं और Cinevva उस अहसास को पकड़ सकता है, भले ही वह पूरी फ्रैंचाइज़ न बना सके। अनुभव को बताना ब्रांड का नाम लेने से हर बार बेहतर होता है।

इसे छोटा बनने दें, फिर बढ़ाएं

Cinevva जानबूझकर पहली ही बारी में एक खेलने लायक हिस्सा बनाता है। जिन creators के हाथ आखिर में कुछ ऐसा लगता है जो उन्हें पसंद आता है, वे सब कुछ शुरुआती prompt में ठूंसने की कोशिश नहीं करते। जब वे इसे चलता हुआ देख लेते हैं, तो हर message में एक चीज़ जोड़ते हैं।

"ट्रैफिक की गाड़ियां जोड़ो।" "जंप को ऊंचा करो।" "मुझे दूसरा level दो।" "एक health bar जोड़ो।" हर बदलाव छोटा, तेज़, और जांचने में आसान होता है, और ये मिलकर एक असली गेम बन जाते हैं। पहली ही बारी में दस features ठूंसने की कोशिश आमतौर पर आपको उन दसों का एक कमज़ोर version देती है। एक बार में एक साफ बदलाव, अच्छे गेम इसी तरह बनते हैं।

जब कुछ गलत हो, तो ठीक-ठीक बताएं कि क्या

सबसे आम message जो मदद नहीं करता वो है "यह काम नहीं करता", या बस "इसे ठीक करो"। AI आपकी स्क्रीन नहीं देख सकता, इसलिए उसे अंदाज़ा लगाना पड़ता है।

उसे तीन चीज़ें बताएं: आपने क्या किया, क्या हुआ, और आपने क्या उम्मीद की थी। "जब मैं स्पेस दबाता हूं तो चिड़िया बस थोड़ा उछलती है, मैं चाहता था कि वह ऊंचा फड़फड़ाए" पहली ही बार में एक असली fix दिलाता है। "गाड़ी दीवारों के बीच रुकने के बजाय उनमें से गुज़र जाती है" सीधे collision detection की तरफ इशारा करता है। ये अतिरिक्त दस शब्द आपको तीन दौर की आगे-पीछे की बातचीत से बचा लेते हैं।

चीज़ें कैसी दिखें, इस बारे में ठोस रहें

Cinevva visuals में तब अच्छा होता है जब आप उसे कल्पना करने के लिए कुछ देते हैं। रंग, आकार, माहौल, किरदार की बारीकियां। एक creator ने अपने हीरो को "एक गहरे रंग की आकृति जिसके पास सफेद केप, सफेद दस्ताने, और चमकती सफेद आंखें हैं" बताया और उसे ठीक वही वापस मिला।

"इसे और कूल बनाओ" AI को काम करने के लिए कुछ नहीं देता। इसके बजाय, palette का नाम लें, vibe (neon, cozy, retro, horror, hand-drawn) बताएं, और कोई भी अहम किरदार या दुनिया की बारीकियां जो आपके लिए मायने रखती हैं। कुछ ठोस शब्द पूरा लुक बदल देते हैं।

अपनी कला खुद लाएं

आप उसी तक सीमित नहीं हैं जो AI बनाता है। अपनी खुद की images सीधे chat में डालें और यह उन्हें textures, sprites, या backgrounds की तरह इस्तेमाल करेगा। या बिना attribution की झंझट वाले मुफ्त 3D models लाने के लिए asset library खोलें। जब आपके दिमाग में कोई खास लुक हो, तो एक reference image देना अक्सर उसे बताने की कोशिश करने से बेहतर काम करता है।

पहला build धीमा होता है, और आपका काम सेव रहता है

पहला build सबसे लंबा लगता है क्योंकि Cinevva आपका पूरा गेम शुरू से लिख रहा होता है। उसके बाद, edits सेकंडों में वापस आते हैं। तो उस पहले इंतज़ार में डटे रहें, यह वाकई इस session का सबसे बुरा इंतज़ार होगा।

और हां, आपके गेम सेव रहते हैं। tab बंद करें, कल वापस आएं, My games खोलें, और ठीक वहीं से आगे बढ़ें जहां आपने छोड़ा था। जब आप जाते हैं तो कुछ भी गायब नहीं होता।

एक अच्छा prompt, शुरू से आखिर तक

सब कुछ मिलाकर, एक दमदार शुरुआत ऐसी दिखती है:

"एक top-down twin-stick shooter। मैं एक neon arena में एक छोटा रोबोट हूं, दुश्मनों की लहरें करीब आ रही हैं, और मैं ज़िंदा रहने के लिए बचता और गोली चलाता हूं। इसे तेज़ और आर्केड जैसा बनाओ।"

यह एक genre, एक किरदार, एक सेटिंग, एक मुख्य लूप, और एक अहसास है, सब कुछ चार छोटे वाक्यों में। इसे बनाएं, चलता हुआ देखें, फिर जोड़ना शुरू करें। हर पांच लहरों पर एक boss। shift key पर एक dash। कॉम्बो के लिए एक score multiplier। इसी तरह एक वाक्य एक ऐसे गेम में बदल जाता है जिसे आप वाकई साझा करना चाहते हैं।

आज़माने के लिए तैयार हैं? creator खोलें और मुफ्त में बनाना शुरू करें →

आखिरी बार अपडेट किया गया: जून 2026.

बिना कोड के 2D गेम बनाना सालों से मुमकिन रहा है। लेकिन ब्राउज़र में चलने वाला 3D गेम, वो भी बिना कोड के, बनाना हैरानी की हद तक मुश्किल रहा है, और ज्यादातर गाइड चुपके से इससे बचते हुए आपको कोई 2D टूल थमा देते हैं। यह गाइड ऐसा नहीं करती। यहां 2026 में ब्राउज़र में 3D-no-code की ईमानदार हकीकत है, और वो रास्ता जो अब सच में काम करता है।

no-code 3D की असहज सच्चाई

क्लासिक no-code गेम बिल्डर बड़े पैमाने पर 2D हैं। जो कुछ शुद्ध no-code 3D टूल ब्राउज़र में चलते थे, वे ज्यादातर बंद हो गए या रास्ता बदल गए:

• Struckd, जो वेब पर सच्चे drag-and-drop 3D के सबसे करीब था, अगस्त 2026 में अपना स्टूडियो बंद कर रहा है।
• Crayta 2023 में ही बंद हो गया।
• Core no-code 3D करता है लेकिन यह सिर्फ डाउनलोड वाला क्लाइंट है, ब्राउज़र गेम नहीं।
• PlayCanvas एक शानदार वेब 3D engine है, लेकिन यह आपसे JavaScript लिखवाता है, तो यह असल में no-code नहीं है।

इससे एक बड़ी खाई बन जाती है। अगर आपको 3D चाहिए, ब्राउज़र में, बिना कोड के, तो क्लासिक विजुअल-बिल्डर की दुनिया के पास एक अपवाद को छोड़कर देने के लिए लगभग कुछ नहीं बचा है।

एक क्लासिक अपवाद: GDevelop

GDevelop एक फ्री, ओपन-सोर्स, विजुअल गेम बिल्डर है जो ब्राउज़र में चलता है और 2025 के आखिर से 3D में जमकर निवेश कर रहा है। आप कोड की जगह विजुअल इवेंट शीट्स से लॉजिक बनाते हैं, इसमें एक अलग 3D एडिटर और 3D फिजिक्स है, और यह gd.games पर एक शेयर लिंक के साथ वेब पर पब्लिश करता है। यह मुख्य रूप से 2D टूल है जिसमें 3D बढ़ रहा है, तो यह किसी समर्पित 3D engine की बराबरी नहीं करेगा, लेकिन ब्राउज़र में सच्चे no-code 3D के लिए यह सबसे मजबूत क्लासिक विकल्प है। इसने एक AI एजेंट भी जोड़ा, जो दूसरे रास्ते तक ले जाता है।

वो रास्ता जो 2026 में सच में काम करता है: AI prompt-to-game

बदलाव यहां है। 2026 में बिना कोडिंग के 3D ब्राउज़र गेम बनाने का सबसे व्यावहारिक तरीका कोई विजुअल एडिटर है ही नहीं, बल्कि गेम को AI को बयां करना और उसे किसी वेब engine पर एक असली 3D गेम बनाने देना है। इसे कभी-कभी vibe coding कहते हैं, और खास तौर पर 3D के लिए यह चुपचाप भरोसेमंद रास्ता बन गया है, जबकि क्लासिक no-code 3D टूल फीके पड़ते गए।

कुछ टूल यह करते हैं:

• Cinevva एक Three.js-आधारित engine पर टेक्स्ट प्रॉम्प्ट से सच में 3D, ब्राउज़र में खेलने लायक गेम बनाता है, जिसमें बिल्ट-इन 3D मॉडल, इमेज, म्यूजिक और skybox जनरेशन के साथ तुरंत शेयर करने लायक लिंक मिलता है।
• Rosebud prompt-to-game करता है जिसमें 2D और बढ़ता हुआ 3D दोनों है, ब्राउज़र में होस्टेड।
• Nilo ब्राउज़र-आधारित AI 3D है जिसमें मजबूत Roblox-एक्सपोर्ट का पहलू है, कम उम्र के दर्शकों के लिए बना।

इनमें से किसी में आप कोड नहीं लिख रहे। आप गेम बयां करते हैं, नतीजा खेलते हैं, और बदलाव मांगकर उसे बेहतर करते हैं। ये कैसे अलग हैं, इसके लिए पूरी AI game generators की तुलना देखें।

AI से 3D ब्राउज़र गेम कैसे बनाएं, कदम दर कदम

1. एक छोटा 3D गेम बयां करें

जॉनर बताएं, एक खास डिटेल, और एक लक्ष्य। 3D तब सबसे अच्छा चलता है जब कॉन्सेप्ट सरल और स्थानिक हो। जैसे:

एक फर्स्ट-पर्सन parkour गेम बनाओ जहां मैं तैरते हुए द्वीपों के बीच कूदूं और अंत तक पहुंचने के लिए टाइमर से रेस लगाऊं।

आप खाली प्रॉम्प्ट से शुरू कर सकते हैं या कोई वन-क्लिक 3D प्रॉम्प्ट लेकर उसे बदल सकते हैं।

2. इसे खेलें, फिर एक चीज़ बदलें

आपको एक खेलने लायक 3D सीन मिलेगा। इसे खेलें और सबसे बड़ी एक ही दिक्कत चुनें। बस वही एक बदलाव मांगें: "कूद को और दूर तक पहुंचाओ," "गिरने पर respawn जोड़ो," "प्लेयर को तेज़ करो।" बदलें, खेलें, दोहराएं। यही लूप पूरा हुनर है।

3. 3D एसेट्स जोड़ें

आपको जो मॉडल और लुक चाहिए वो मांगें: "प्लेयर को एक low-poly रोबोट दो," "सनसेट skybox इस्तेमाल करो," "द्वीपों को पत्थर का बनाओ जिनके ऊपर घास हो।" अगर टूल में CC0 एसेट लाइब्रेरी है, तो जो कुछ भी आप पब्लिश करेंगे उसके लिए उस पर भरोसा करें। हमारी फ्री गेम एसेट्स गाइड स्रोत और लाइसेंस समझाती है।

4. इसे गेम जैसा एहसास दें

वो आखिरी टच जोड़ें जो प्लेयर 3D में नोटिस करते हैं: एक साफ कैमरा, रिस्पॉन्सिव कंट्रोल, एक दिखने वाला लक्ष्य, अहम एक्शन पर आवाज़, और एक जीत या हार की स्थिति। एक टाइटल स्क्रीन और एक रीस्टार्ट बटन मांगें।

5. लिंक पब्लिश करें

ब्राउज़र टूल आपको एक क्लिक में शेयर करने लायक URL देते हैं। इसे इधर-उधर भेजें, देखें लोग कहां छोड़ देते हैं, और उसे अपने अगले दौर के बदलावों में बदल दें।

हाथ से करने का क्या?

अगर आप थोड़ा कोड सीखने को तैयार हैं, तो वेब 3D की दुनिया समृद्ध है: Three.js, Babylon.js, और PlayCanvas सभी बेहतरीन ब्राउज़र 3D बनाते हैं, और Godot जैसे engine भी वेब पर एक्सपोर्ट करते हैं। यह no-code नहीं है, लेकिन जानने लायक है कि उस रेखा को पार करने के बाद छत काफी ऊंची है। हमारी web game engines की तुलना उन विकल्पों को कवर करती है। सच में no-code बने रहने के लिए, GDevelop या कोई AI prompt-to-game टूल ही जवाब है।

आम सवाल

क्या बिना कोडिंग के ब्राउज़र में 3D गेम बनाया जा सकता है?

हां, लेकिन विकल्प सीमित हैं। GDevelop असली ब्राउज़र 3D वाला मुख्य क्लासिक no-code टूल है, और Cinevva, Rosebud और Nilo जैसे AI prompt-to-game टूल आपको कोडिंग की जगह गेम बयां करके 3D ब्राउज़र गेम बनाने देते हैं। कई पुराने शुद्ध no-code 3D टूल (Struckd, Crayta) बंद हो चुके हैं, तो 2026 में व्यावहारिक रास्ते GDevelop या AI रूट हैं।

बिना किसी अनुभव के 3D गेम बनाने का सबसे आसान तरीका क्या है?

किसी AI prompt-to-game टूल को गेम बयां करें और चैट करके उसे बेहतर बनाएं। आपको मिनटों में एक खेलने लायक 3D गेम मिलता है, न कोई engine इंस्टॉल करना पड़ता है न कोड लिखना, फिर आप एक-एक बदलाव से उसे सुधारते हैं। पूरी तरह नए इंसान के लिए यह सबसे कम रुकावट वाला शुरुआती बिंदु है।

क्या GDevelop 3D के लिए अच्छा है?

GDevelop मुख्य रूप से एक 2D engine है, लेकिन इसने 2025 के आखिर से एक अलग 3D एडिटर, 3D फिजिक्स और 3D फीचर जोड़े हैं, और यह फ्री, ओपन-सोर्स, ब्राउज़र-आधारित है जिसमें वेब पब्लिशिंग है। यह किसी समर्पित 3D engine की बराबरी नहीं करेगा, लेकिन ब्राउज़र में फ्री no-code 3D के लिए यह सबसे मजबूत क्लासिक विकल्प है।

क्या 3D ब्राउज़र गेम बनाने के लिए ताकतवर कंप्यूटर चाहिए?

नहीं। ब्राउज़र-आधारित AI टूल और GDevelop भारी काम अपने सर्वर पर या खुद ब्राउज़र में करते हैं, तो आपको गेमिंग PC या समर्पित GPU की ज़रूरत नहीं। कोई भी ठीक-ठाक आधुनिक कंप्यूटर और एक मौजूदा ब्राउज़र बनाने और खेलने के लिए काफी है।

संबंधित

• 2026 में सबसे अच्छे AI Game Generators — वो टूल जो प्रॉम्प्ट से 3D बनाते हैं
• AI से गेम कैसे बनाएं (बिना कोडिंग) — पूरा शुरुआती वर्कफ़्लो
• Vibe Coding Games: यह क्या है और कैसे शुरू करें — प्रॉम्प्ट-चालित तरीका समझाया गया
• AI Game Prompts जिन्हें आप एक क्लिक में बना सकते हैं — 3D शुरुआती बिंदु
• 2026 के लिए सबसे अच्छे Web Game Engines — अगर आप थोड़ा कोड सीखने का फैसला करें
• फ्री गेम एसेट्स कहां मिलेंगी — 3D मॉडल और टेक्सचर

आख़िरी अपडेट: जून 2026।

2026 में किसी game asset को generate करना अक्सर सही मुफ़्त asset ढूँढने से ज़्यादा तेज़ होता है। एक prop describe करें, एक मिनट से भी कम में textured 3D model पा लें। एक mood टाइप करें, music पा लें। यह गाइड 3D, textures और audio में games के लिए सबसे बेहतरीन AI asset generators को कवर करती है, हर एक किस काम में अच्छा है, और वह licensing की पेच जो कुछ भी ship करने से पहले आपको देखनी होगी।

Licensing की पेच (यह पहले पढ़ें)

ज़्यादातर hosted AI generators आपको मुफ़्त में बनाने देते हैं, पर commercial rights को paid plan के पीछे रखते हैं, और free-tier का output अक्सर non-commercial होता है। जिन open models को आप खुद host करते हैं वे commercial use के लिए आमतौर पर सबसे साफ़ होते हैं, पर हर एक का अपना license होता है (कुछ कुछ क्षेत्रों को बाहर रखते हैं)। AI से बनी कोई चीज़ ship करने से पहले उस model की output-rights की शर्तें ज़रूर जाँच लें। संदेह हो तो permissive license वाला open model इस्तेमाल करें या ऐसा paid tier जो commercial rights देता हो।

3D model generators

Hosted (शुरू करने में सबसे तेज़)

• Meshy — text या image से PBR materials वाला textured, riggable 3D mesh। Free tier non-commercial है, commercial Pro पर। सबसे लोकप्रिय all-rounder। meshy.ai
• Tripo — text या image से 3D, 4K PBR और auto-rigging के साथ। Free tier non-commercial। मज़बूत, game पर केंद्रित output। tripo3d.ai
• Rodin / Hyper3D — साफ़ quad topology, generate करना मुफ़्त और download के लिए भुगतान। तब अच्छा जब आपको mesh topology की परवाह हो। hyper3d.ai
• Sloyd — game पर केंद्रित parametric और AI generation, paid tier पर commercial। sloyd.ai

Open (self-host, commercial-friendly)

• Hunyuan3D 2.1 (Tencent) — open weights और training code, production PBR texturing। ध्यान दें इसका license EU, UK और South Korea को बाहर रखता है, तो उन क्षेत्रों में ship करने से पहले जाँच लें। Cinevva इसे 3D Model Generator के तौर पर चलाता है।
• TRELLIS.2 (Microsoft) — MIT-licensed, मौजूदा open image-to-3D leader, native PBR।
• SAM 3D (Meta) — एक photo से 3D, objects और human bodies के लिए। Cinevva इसे in-browser image-to-3D object capture के तौर पर चलाता है जो एक Gaussian splat output करता है।
• Roblox Cube 3D — open-sourced text-to-mesh।

Texture और image generators

Tileable textures, sprites, concept art और UI के लिए:

• FLUX.2 (Black Forest Labs) — मज़बूत text-to-image और editing, स्वतंत्र रूप से commercial open विकल्प klein 4B (Apache 2.0) है।
• Qwen-Image (Alibaba) — open, Apache 2.0, best-in-class text rendering के साथ (signage और labels के लिए बढ़िया)।
• Stable Diffusion 3.5 — गहरे customization के लिए परिपक्व ecosystem (ControlNet, inpainting, LoRAs)।

ये models seamless textures और 2D art generate करते हैं जिन्हें आप सीधे game में डाल सकते हैं। पूरी लाइनअप और licenses के लिए हमारी open generative AI models guide देखें।

Audio generators (music और SFX)

• Stable Audio 3.0 — एक Small model के लिए open weights और साथ में एक dedicated open sound-effects model, licensed data पर trained (साफ़ legal आधार)। game SFX के लिए सबसे मज़बूत open विकल्प।
• ACE-Step 1.5 — open, MIT-licensed music generation, कई भाषाओं में voice cloning के साथ।
• ElevenLabs — SFX और music के लिए सबसे मज़बूत hosted विकल्प, paid plans पर commercial rights।

Rigging और animation

Auto-rigging परिपक्व हो चुका है: UniRig (MIT) और NVIDIA SOMA-X (Apache 2.0) जैसे open models आपके meshes के लिए skeletons और skinning generate करते हैं, यह Mixamo का भरोसेमंद विकल्प है जो अब अविश्वसनीय हो गया है। Tripo और Meshy जैसे hosted tools भी auto-rig करते हैं। Cinevva का Auto Rigger यह browser में करता है: एक GLB, FBX या OBJ upload करें और optional preset animations के साथ rigged model वापस पाएँ।

तुलना

All-in-one विकल्प

इन tools को आपस में जोड़ना काम करता है, पर यह एक pipeline है। कुछ game creators generation को editor में ही bundle कर देते हैं: Cinevva में text-to-3D, image, music और skybox generation पहले से built-in है, ताकि आप एक asset generate कर सीधे अपने game में डाल सकें, tools के बीच export और import किए बिना। आप इसे मुफ़्त आज़मा सकते हैं।

आम सवाल

Games के लिए सबसे बेहतरीन AI 3D model generator कौन सा है?

Hosted tools के लिए, Meshy और Tripo अग्रणी all-rounders हैं (text या image से textured, riggable mesh), paid plans पर commercial rights के साथ। Open, self-hostable models के लिए, Hunyuan3D 2.1 और Microsoft का TRELLIS.2 2026 में सबसे मज़बूत हैं। सबसे अच्छा विकल्प इस पर निर्भर करता है कि आप एक तेज़ hosted tool चाहते हैं या commercial-friendly open weights।

क्या मैं commercial game में AI-generated assets इस्तेमाल कर सकता हूँ?

अक्सर हाँ, पर license जाँच लें। जिन open models को आप खुद host करते हैं वे आमतौर पर सबसे साफ़ होते हैं (ध्यान दें Hunyuan3D कुछ क्षेत्रों को बाहर रखता है)। Hosted tools आमतौर पर commercial rights को paid plan के पीछे रखते हैं, और free-tier का output अक्सर non-commercial होता है। हमेशा model की output-rights की शर्तें पक्की करें, और जहाँ आपका platform ज़रूरी बनाए वहाँ AI content का खुलासा करें।

क्या मुफ़्त AI asset generators हैं?

कई tools में free tiers हैं, पर वे आमतौर पर usage सीमित करते हैं और commercial rights बाहर रखते हैं। TRELLIS.2, FLUX.2 klein, Qwen-Image और Stable Audio जैसे open models अगर आपके पास hardware हो तो commercial-friendly licenses के साथ खुद चलाने के लिए मुफ़्त हैं। ऊपर की तुलना तालिका दिखाती है कौन सा open है और कौन सा hosted।

क्या AI game music और sound effects generate कर सकता है?

हाँ। Stable Audio 3.0 एक dedicated sound-effects model समेत open weights देता है, ACE-Step MIT license के तहत music generate करता है, और ElevenLabs paid plans पर commercial rights के साथ एक मज़बूत hosted विकल्प है। ये एक game के पूरे soundscape के लिए music और SFX दोनों कवर करते हैं।

संबंधित

• Games के लिए सबसे बेहतरीन ओपन-सोर्स जनरेटिव AI मॉडल — गहरा technical विवरण
• मुफ़्त Game Assets कहाँ मिलेंगे — पहले से बने मुफ़्त assets
• Games के लिए सबसे बेहतरीन मुफ़्त 3D Model साइट्स — generate करने की बजाय search करें
• Games के लिए मुफ़्त Sound Effects और Music — पहले से बना audio
• Game Asset Licenses की व्याख्या — शर्तों को समझना

आखिरी बार अपडेट किया गया: जून 2026.

आप एक वाक्य टाइप करते हैं, AI एक गेम बना देता है। यही वादा है, और 2026 में यह असली है, लेकिन जो tools ऐसा करते हैं वे अंदर से बहुत अलग हैं। कुछ आपके browser में पॉलिश किए हुए 2D आर्केड गेम बनाते हैं। कुछ desktop engine हैं जो आपको एक ऐसा प्रोजेक्ट देते हैं जिसके आप पूरी तरह मालिक होते हैं। कुछ सामान्य code assistant हैं जो गेम भी बना सकते हैं। गलत वाला चुनने से एक पूरा वीकेंड बर्बाद हो जाता है।

यह गाइड 2026 में जानने लायक AI गेम जनरेटर की तुलना करती है, हर एक असल में क्या बनाता है, क्या आप अपने गेम के मालिक बन सकते हैं और उसे export कर सकते हैं, और उसकी कीमत क्या है। हमने ईमानदार रहने की कोशिश की है कि हर tool कहां जीतता है, इसमें यह भी शामिल है कि हमारा tool कहां जीतता है और कहां नहीं।

"AI गेम जनरेटर" के चार प्रकार

ज्यादातर "सबसे अच्छे AI गेम मेकर" वाली लिस्ट इन्हें आपस में मिला देती हैं, इसीलिए वे उलझन भरी होती हैं। असल में चार श्रेणियां हैं:

1. Prompt-to-game builders एक विवरण से खेलने लायक गेम बनाते हैं। Rosebud, Gameer, Astrocade, Nilo और Cinevva यहां आते हैं।
2. Engine-integrated AI agents एक मौजूदा engine के अंदर AI assistant जोड़ते हैं। GDevelop AI, Buildbox 4 और Unity AI ऐसे ही हैं।
3. General code builders जैसे Replit एक गेम बना सकते हैं क्योंकि वे कोई भी web app बना सकते हैं, लेकिन वे games-native नहीं हैं।
4. Ideation और asset tools जैसे Ludo.ai आपको योजना बनाने और assets जनरेट करने में मदद करते हैं लेकिन तैयार गेम नहीं बनाते।

आपको कौन सी श्रेणी चाहिए यह जान लेने से विकल्प जल्दी सिमट जाते हैं।

झटपट चुनाव

• Browser में सबसे तेज खेलने लायक नतीजा: Rosebud या Cinevva।
• आप code के मालिक बनना चाहते हैं और Steam पर शिप करना चाहते हैं: Summer Engine।
• Interactive fiction और visual novel: Gameer।
• मुफ्त और open-source, web hosting के साथ: GDevelop AI।
• prompt से 3D गेम, तुरंत link से शेयर करने लायक: Cinevva या Nilo।
• आप पहले से Unity या web dev हैं: Unity AI या Replit।

तुलना तालिका

कीमतें अनुमानित हैं और अक्सर बदलती रहती हैं, इसलिए checkout पर पुष्टि कर लें। Free tiers आमतौर पर commercial rights पर पाबंदी लगाते हैं, इसलिए बेचने के इरादे से कुछ भी शिप करने से पहले शर्तें जांच लें।

एक-एक tool

Rosebud AI

Rosebud prompts को browser में खेलने लायक गेम में बदल देता है और 2D में सबसे मजबूत है, बढ़ते हुए 3D और voxel support के साथ। अंदर से यह JavaScript जनरेट करता है (3D के लिए Three.js, 2D के लिए Phaser), इसलिए output सिद्धांत रूप में portable है। आप इसके assistant से चैट करके iterate करते हैं, यह आपके लिए sprites और NPC जनरेट करता है, और आप एक shareable, Rosebud पर hosted URL पर publish करते हैं। Free tier आपको हफ्ते में कुछ prompts देता है बिना commercial rights के, paid plans commercial इस्तेमाल खोल देते हैं। उन शुरुआती लोगों, शिक्षकों और jam entries के लिए सबसे अच्छा जो 2D link तक सबसे तेज रास्ता चाहते हैं।

Summer Engine

Summer वह चुनाव है अगर आप एक असली गेम शिप करके बेचना चाहते हैं और हर चीज के मालिक बनना चाहते हैं। यह एक desktop, AI-native engine है जिसे Godot 4 के drop-in के तौर पर पेश किया गया है, इसलिए आपका प्रोजेक्ट standard Godot files (GDScript या C#) होता है, बिना किसी lock-in के। आप chat में scenes और logic का वर्णन करते हैं, यह code और assets जनरेट करता है, और आप Windows, macOS, Linux, mobile, web और Steam पर export करते हैं, अपनी पूरी कमाई अपने पास रखते हुए। browser tools की तुलना में समझौता यह है: यह एक desktop app है जिसका लक्ष्य stores पर शिप करना है, न कि तुरंत एक public link। ध्यान देने लायक बात है कि Summer खुद बहुत सारे "सबसे अच्छे AI गेम मेकर" वाले राउंडअप छापता है जो Summer को पहले नंबर पर रखते हैं, इसलिए उन्हें उसी हिसाब से तौलें।

Gameer

Gameer कुछ ही मिनटों में एक सादे-text prompt से सिनेमाई interactive-story और visual-novel गेम बनाता है, बिना किसी code के। एक multi-agent सिस्टम कथा, visuals और mechanics संभालता है। आपको तुरंत एक shareable link मिलता है, हालांकि गेम Gameer के runtime से locked रहता है। यह उन लेखकों, शिक्षकों और marketers के लिए बना है जो branching fiction चाहते हैं, न कि real-time action या 3D।

GDevelop AI

GDevelop एक मुफ्त, open-source engine है जिसने एक in-editor AI agent जोड़ा है। आप इससे features या पूरे गेम बनाने को कहते हैं और यह आपके editable प्रोजेक्ट में events और behaviors लिख देता है। यह 2D और बढ़ता हुआ 3D करता है, web, Android, iOS और desktop पर export करता है, और आपको gd.games पर मुफ्त public hosting देता है share links के साथ। AI एक मासिक credit भत्ते पर चलता है, paid tiers और जोड़ देते हैं। एक मजबूत मुफ्त, open विकल्प अगर आपको credit limit और थोड़ा iteration मंजूर है।

Replit

Replit का Agent एक सामान्य full-stack builder है, गेम engine नहीं, लेकिन यह एक विवरण से web गेम बना सकता है और उसे एक public URL पर deploy कर सकता है। यह sprites, music या sound जनरेट नहीं करता, इसलिए आप अपने assets खुद लाते हैं, और यह 2D की तरफ झुकता है। उन लोगों के लिए सबसे अच्छा जो पहले से किसी AI coding tool को चलाने में सहज हैं और एक web-playable नतीजा चाहते हैं जिस पर उनका पूरा नियंत्रण हो।

Unity AI

Unity ने अपने पुराने Muse product की जगह Unity AI ला दिया, जो मई 2026 तक open beta में है। यह Unity 6 के अंदर एक in-editor agent है जो frontier models का इस्तेमाल करके C# code, placeholder assets और scenes जनरेट करता है। आप अपने ही Unity प्रोजेक्ट के अंदर रहते हैं और अपने गेम के मालिक होते हैं, WebGL समेत दूसरे targets पर export करते हुए। यह उन लोगों के लिए है जो पहले से Unity में काम करते हैं और AI मदद चाहते हैं, न कि उन नए लोगों के लिए जो एक वाक्य से गेम चाहते हैं।

Buildbox 4, Astrocade, Nilo

Buildbox 4 एक no-code, ज्यादातर hyper-casual mobile engine है जिसने AI asset और node generation जोड़ा; यह HTML5 export करता है लेकिन engine-locked है। Astrocade एक अच्छी फंडिंग वाला, तुरंत-share करने वाला social platform है जिसका output 3D marketing के बावजूद व्यवहार में 2D की तरफ झुकता है, कड़े lock-in और बिना किसी code export के साथ। Nilo browser-based AI 3D tool में हमारे बनाए हुए के सबसे करीब है, एक मजबूत Roblox-export नजरिए और छोटी उम्र के दर्शकों के साथ; यह मुफ्त beta में है।

कैसे चुनें

तीन सवाल पूछें। पहला, क्या आपको 3D चाहिए, या 2D ठीक है? ज्यादातर tools 2D में सबसे मजबूत हैं, और prompt से भरोसेमंद 3D वह मुश्किल पैमाना है जिसे कम ही पार कर पाते हैं। दूसरा, क्या आपको code के मालिक बनकर उसे export करना है, या एक hosted link काफी है? Summer, GDevelop, Unity AI और Cinevva सभी आपको अपना प्रोजेक्ट export करने देते हैं (Cinevva आपको पूरा गेम download करने देता है ताकि आप उसे कहीं भी host कर सकें); Rosebud, Gameer और Astrocade तुरंत shareable link पर टिके रहते हैं। तीसरा, क्या आप Steam और app stores पर शिप कर रहे हैं, या दोस्तों के साथ एक link शेयर कर रहे हैं? Stores desktop engines के पक्ष में हैं; links browser tools के पक्ष में हैं।

Cinevva कहां फिट होता है

हम इस बारे में सीधी बात करेंगे। बाजार का भीड़भाड़ वाला हिस्सा 2D-in-the-browser है (Rosebud, Astrocade, Gameer, Replit)। Cinevva एक बहुत कम भीड़ वाली जगह पर बैठा है: chat-driven, 2D और सच में 3D दोनों गेम बनाता है, एक असली Three.js-based engine पर browser में खेलने लायक, तुरंत link से shareable, और एक पूरे गेम के रूप में exportable जिसे आप download करके कहीं भी host कर सकते हैं, इसमें text-to-3D, image, music और skybox generation और CC0 asset libraries अंदर बने हुए हैं। वह code export मायने रखता है, क्योंकि कई तुरंत-share करने वाले प्रतिद्वंद्वी (Astrocade, Gameer) आपके गेम को अपने runtime से lock कर देते हैं। उस चौराहे के सबसे करीब वाला tool Nilo है, जो 3D assets को Roblox पर export करने की तरफ झुकता है और छोटी उम्र के दर्शकों को target करता है, इसलिए वह self-hosted web गेम जिसे आप शेयर भी कर सकते हैं और download भी, वही खाली जगह है जिस पर हम ध्यान देते हैं।

ईमानदार चेतावनी यह है कि "prompt से असली 3D" इस श्रेणी का सबसे मुश्किल दावा है, और समीक्षक शक करने में सही हैं। इनमें से किसी भी tool को, हमारे वाले समेत, आंकने का सही तरीका है कुछ बनाना और link शेयर करना। आप एक prompt से मुफ्त में 3D गेम बना सकते हैं और देख सकते हैं कि नतीजा कहां पहुंचता है, या अगर आप खाली box घूरना नहीं चाहते तो एक-क्लिक prompt से शुरू करें।

आम सवाल

2026 में सबसे अच्छा AI गेम जनरेटर कौन सा है?

कोई एक सबसे अच्छा नहीं है, क्योंकि tools अलग-अलग लक्ष्य पूरे करते हैं। तेजी से 2D browser गेम के लिए Rosebud बढ़िया है। ऐसे 3D browser गेम के लिए जिसे आप तुरंत शेयर कर सकें, Cinevva या Nilo। ऐसे गेम के लिए जिसके आप मालिक हों और Steam पर शिप करें, Summer Engine। मुफ्त और open-source के लिए, GDevelop AI। इस आधार पर चुनें कि 2D बनाम 3D, क्या आपको code का मालिक बनना है, और क्या आप एक link शेयर कर रहे हैं या किसी store पर शिप कर रहे हैं।

क्या AI सच में एक prompt से पूरा गेम बना सकता है?

छोटे और casual गेम के लिए, हां, खासकर 2D। AI movement, collision, physics और बुनियादी art संभाल लेता है ताकि आप idea से खेलने लायक तक कुछ ही मिनटों में पहुंच जाएं। बड़े या ज्यादा पॉलिश किए हुए गेम को अब भी iteration और इंसानी design काम की जरूरत होती है, और AI के लिए 3D को सही करना 2D से मुश्किल है। पहली generation को एक मजबूत शुरुआती बिंदु मानें जिसे आप निखारते हैं, तैयार product नहीं।

क्या AI गेम जनरेटर से बनाए गेम के मालिक मैं होता हूं?

यह tool पर निर्भर करता है। Summer, GDevelop और Unity AI जैसे engine-based tools आपको एक असली प्रोजेक्ट देते हैं जिसके आप मालिक होते हैं और जिसे export कर सकते हैं। Hosted prompt-to-game platforms अलग-अलग होते हैं: कुछ आपको code export करने देते हैं, कुछ गेम को अपने runtime से lock कर देते हैं, और कई commercial rights को paid plan के पीछे रखते हैं। कुछ भी बेचने से पहले हमेशा शर्तें पढ़ें।

क्या AI-generated गेम बनाना मुफ्त है?

ज्यादातर tools का एक free tier होता है जो उन्हें आजमाने के लिए काफी अच्छा है, लेकिन free tiers आमतौर पर सीमित कर देते हैं कि आप कितना जनरेट कर सकते हैं और अक्सर commercial rights को बाहर रखते हैं। जब आप commercially publish करना चाहें, भारी मात्रा में जनरेट करना चाहें, या export करना चाहें तो भुगतान की उम्मीद रखें। ऊपर की तुलना तालिका हर tool का free tier और सबसे सस्ता paid plan बताती है।

संबंधित

• AI से गेम कैसे बनाएं (2026 गाइड) — पूरा no-code वर्कफ़्लो, कदम दर कदम
• बिना coding के 3D browser गेम कैसे बनाएं — 3D-विशिष्ट रास्ता
• Vibe Coding Games: यह क्या है और शुरुआत कैसे करें — यह शब्द, वर्कफ़्लो, खतरे
• AI गेम Prompts जो आप एक क्लिक में बना सकते हैं — आजमाने के लिए शुरुआती बिंदु
• 2026 के लिए सबसे अच्छे Web Game Engines — अगर आप हाथ से बनाना चाहें
• गेम के लिए सबसे अच्छे Open-Source Generative AI Models — AI asset generation के पीछे के models

आखिरी अपडेट: जून 2026.

जब आप शुरुआत कर रहे हों, तो सबसे अच्छा इंजन वही है जो बिना किसी बिल और बिना कोड की मोटी दीवार के आपको सबसे तेजी से एक playable गेम तक पहुंचा दे। 2026 में अच्छी खबर यह है कि शुरुआती लोगों के लिए सबसे मजबूत विकल्प पूरी तरह मुफ्त हैं। यहां वे विकल्प हैं, इस आधार पर क्रम में लगाए गए कि आप कितना कोड लिखना चाहते हैं, साथ ही नया "इसे AI को बताएं" वाला रास्ता।

आप कहां से शुरू कर रहे हैं, उसके हिसाब से क्विक पिक

• बिल्कुल कोड नहीं, आज ही गेम चाहिए: GDevelop, या कोई AI prompt-to-game टूल।
• थोड़ा कोड, ठीक से सीखना चाहते हैं: Godot।
• आपको कुछ JavaScript आता है: Phaser।
• साफ-सुथरे एडिटर के साथ visual scripting: Construct (मुफ्त टियर) या GDevelop।

सबसे अच्छे मुफ्त इंजन

GDevelop

मुफ्त, open-source, आपके browser में या डेस्कटॉप ऐप के रूप में चलता है, और आप कोड की जगह visual event sheets के साथ logic बनाते हैं। यह 2D करता है और तेजी से 3D भी, web, mobile और डेस्कटॉप पर export करता है, और gd.games पर एक share link के साथ मुफ्त hosting देता है। इसने एक AI agent भी जोड़ा है जो prompts से features बना सकता है। ज्यादातर शुरुआती लोगों के लिए यह अकेला सबसे अच्छा no-code शुरुआती बिंदु है, और शिप करने की कोई कीमत नहीं।

Godot

MIT license के तहत मुफ्त और open-source, कभी कोई फीस या revenue cap नहीं। Godot 2D और 3D दोनों करता है, इसकी scripting language (GDScript) सरल है और आसान समझने के लिए बनाई गई है, और मुफ्त tutorials की एक बड़ी लाइब्रेरी है। मौजूदा version 4.7 है (जून 2026)। अगर आप licensing की चिंता किए बिना असली game programming सीखना चाहते हैं, तो यह सबसे अच्छा विकल्प है, और यह आपके पहले प्रोजेक्ट से लेकर एक पूरे गेम को शिप करने तक आपके साथ बढ़ता है। एक बात ध्यान दें: C# प्रोजेक्ट web पर export नहीं हो सकते, इसलिए अगर आपका लक्ष्य web है तो GDScript का इस्तेमाल करें।

Phaser

MIT license के तहत मुफ्त, Phaser सबसे लोकप्रिय HTML5 game framework है, जिसका सबसे बड़ा community और 2D web गेम्स के लिए सबसे ज्यादा tutorials हैं। Version 4, 2026 में आया। यह code-first है (JavaScript या TypeScript), इसलिए यह उन शुरुआती लोगों के लिए सही है जिन्हें पहले से थोड़ा web development आता है और जो visual एडिटर के बजाय कोड लिखकर सीखना चाहते हैं।

Construct (मुफ्त टियर)

Construct एक visual, event-sheet इंजन है जो बिना किसी coding के browser में चलता है। इसका मुफ्त टियर आपको 2D गेम्स बनाकर web पर publish करने देता है, कुछ सीमाओं के साथ (events और layers पर एक cap) जिन्हें प्रोजेक्ट बड़े होने पर आप पार कर जाते हैं। उन बिल्कुल नए लोगों के लिए बढ़िया है जो एक साफ-सुथरा, guided एडिटर चाहते हैं, और subscription तभी चाहिए जब आप बड़े स्तर पर जाएं।

AI / no-code वाला रास्ता

एक नया विकल्प: किसी AI prompt-to-game टूल को एक गेम बताएं और chat करके उसे बेहतर बनाएं, कोई इंजन install किए बिना। किसी idea से एक शेयर करने लायक playable गेम तक पहुंचने का यह सबसे तेज रास्ता है, खासकर 3D के लिए, जहां क्लासिक no-code टूल कमजोर हैं। देखें AI के साथ गेम कैसे बनाएं और हमारी AI game generators की तुलना।

तुलना

अपना पहला इंजन कैसे चुनें

इस पर ज्यादा मत सोचिए। इंजन को इस बात से मिलाइए कि आप कितना कोड लिखना चाहते हैं, और छोटी शुरुआत कीजिए। अगर कोड का विचार अच्छा नहीं लगता, तो GDevelop से शुरू कीजिए और इसी हफ्ते एक छोटा गेम शिप कीजिए। अगर आप design के साथ-साथ programming भी सीखना चाहते हैं, तो Godot से शुरू कीजिए और इसके कई शुरुआती tutorials में से किसी एक को फॉलो कीजिए। अगर आपको पहले से JavaScript आता है, तो Phaser स्वाभाविक लगेगा। और अगर आप बस अपना idea जितनी जल्दी हो सके playable देखना चाहते हैं, तो AI वाला रास्ता आजमाइए, फिर जैसे-जैसे आपके प्रोजेक्ट बढ़ें, किसी code या visual इंजन पर चले जाइए। शुरुआती लोग सबसे बड़ी गलती यह करते हैं कि एक भारी professional इंजन चुन लेते हैं, घबरा जाते हैं, और छोड़ देते हैं। किसी सरल इंजन में बना एक पूरा छोटा गेम आपको एक अधूरे बड़े गेम से ज्यादा सिखाता है।

आम सवाल

शुरुआती लोगों के लिए सबसे आसान मुफ्त गेम इंजन कौन सा है?

GDevelop सबसे आसान मुफ्त शुरुआती बिंदु है: यह no-code है (visual event sheets), browser में चलता है, और web पर मुफ्त publish करता है। Construct भी इसी तरह शुरुआती लोगों के लिए अनुकूल है और इसका एक मुफ्त टियर है। अगर आप बिल्कुल कोई setup नहीं चाहते, तो कोई AI prompt-to-game टूल एक description से आपको एक playable गेम देता है।

क्या Godot शुरुआती लोगों के लिए अच्छा है?

हां। Godot मुफ्त और open-source है, और इसकी scripting language (GDScript) शुरुआती लोगों के लिए अनुकूल है, साथ में मुफ्त tutorials की एक बड़ी लाइब्रेरी भी। अगर आप असली game programming सीखना चाहते हैं तो यह सबसे अच्छा मुफ्त विकल्प है, और यह 2D और 3D दोनों करता है। बस ध्यान रखें कि C# प्रोजेक्ट web पर export नहीं हो सकते, इसलिए अगर आपका लक्ष्य browsers हैं तो GDScript पर ही रहिए।

गेम बनाने के लिए क्या मुझे कोड करना आना चाहिए?

नहीं। GDevelop और Construct जैसे no-code इंजन आपको visual logic के साथ गेम्स बनाने देते हैं, और AI prompt-to-game टूल सादी अंग्रेजी में दिए गए description से एक गेम बना देते हैं। Coding आपको ज्यादा control देती है और आगे चलकर इसे सीखना फायदेमंद है, लेकिन आप इसके बिना भी आज एक असली गेम बनाकर publish कर सकते हैं।

2026 में मुझे कौन सा मुफ्त इंजन सीखना चाहिए?

इस आधार पर चुनिए कि आप कितना कोड लिखना चाहते हैं: no-code के लिए GDevelop या कोई AI टूल, programming सीखने के लिए Godot, और अगर आपको JavaScript आता है तो Phaser। ये सभी commercial गेम्स शिप करने के लिए मुफ्त हैं। उसी से शुरू कीजिए जो आपके लिए रुकावट को कम करे, एक छोटा गेम पूरा कीजिए, और वहां से आगे बढ़िए।

संबंधित

• 2026 के लिए सबसे अच्छे Web गेम इंजन — जैसे-जैसे आप बढ़ें, पूरा मैदान
• 2026 के लिए सबसे अच्छे 2D गेम इंजन — अगर आपका पहला गेम 2D है
• AI के साथ गेम कैसे बनाएं (बिना Coding) — no-code AI वाला रास्ता
• बिना Coding के 3D Browser गेम कैसे बनाएं — शुरुआती लोगों के लिए 3D
• itch.io पर अपना गेम कैसे लॉन्च करें — अपना पहला गेम publish करना

आखिरी बार अपडेट किया गया: जून 2026.

आपको हर चीज़ खुद मॉडल करने या उसके लिए पैसे देने की ज़रूरत नहीं है। बाहर free, game-ready 3D models का एक गहरा भंडार मौजूद है, और इनमें सबसे अच्छे CC0 हैं, यानी आप इन्हें बिना किसी attribution के commercial तौर पर इस्तेमाल कर सकते हैं। यहाँ 2026 में bookmark करने लायक sites हैं, इस हिसाब से क्रम में लगाई गई हैं कि आप इन्हें असल में कैसे इस्तेमाल करेंगे, और licensing को साफ समझाया गया है।

Quick picks

• Game-ready, एक जैसा style, कोई झंझट नहीं: Kenney, Quaternius (दोनों CC0)।
• Photorealistic models, textures, HDRIs: Poly Haven (CC0)।
• सबसे ज़्यादा variety, जटिल models: Sketchfab (mixed licenses, हर एक जाँचें)।
• Low-poly, Google Poly archive: Poly Pizza, Icosa Gallery (ज़्यादातर CC-BY)।

CC0 के भरोसेमंद विकल्प (कोई attribution नहीं, commercial के लिए सुरक्षित)

Kenney

शुरुआत करने की सबसे अच्छी जगह। Kenney हज़ारों game-ready assets देता है, सब CC0, जिनमें 3D models, sprites, UI, और audio शामिल हैं, एक जैसे art styles में जिन्हें आप मिला-जुला कर इस्तेमाल कर सकते हैं। सब कुछ games के लिए optimized है। अगर आपको जल्दी एक सुसंगत look चाहिए, तो यहीं से शुरू करें। kenney.nl

Quaternius

प्यारे, stylized low-poly 3D models, सब CC0, थीम वाले packs में सजाए गए (characters, environments, vehicles, monsters) और साथ में एक universal animation library। उन indie games के लिए एकदम सही जो एक आकर्षक low-poly aesthetic चाहती हैं। quaternius.com

Poly Haven

Photorealistic 3D models, PBR textures, और HDRIs, सब CC0, कई resolutions और direct downloads के लिए एक no-key API के साथ। 2,000 से ज़्यादा assets और बढ़ते जा रहे हैं। Realistic props, environments, और lighting के लिए सबसे अच्छा। polyhaven.com

बड़ी libraries (mixed licenses, हर एक जाँचें)

Sketchfab

सबसे बड़ी 3D model library, लाखों models और download से पहले एक 3D preview के साथ। हर model की license अलग होती है, इसलिए downloadable के साथ CC0 या CC-BY के लिए filter करें। 2026 की एक बात जानने लायक है: Sketchfab का store Epic के Fab में चला गया, और वहाँ सिर्फ CC-BY और Fab Standard content ही migrate हो सकता है। CC0 और दूसरे Creative Commons models Sketchfab पर downloadable रहते हैं, पर इसे एक धीरे-धीरे घटता हुआ CC0 source मानकर चलें, इसलिए जो चाहिए वह ले लें। sketchfab.com

Poly Pizza और Icosa Gallery

Google Poly 2021 में बंद हो गया, पर इसका low-poly catalog आज भी ज़िंदा है। Poly Pizza पर archived "Poly by Google" collection (करीब 2,294 models) के साथ हज़ारों नए community uploads होस्ट होते हैं, और non-profit Icosa Gallery इस open mission को आगे बढ़ा रही है। ज़्यादातर models CC-BY हैं (creator को credit दें), कुछ CC0 भी। Kenney और Quaternius के look से मेल खाने वाले तेज़, stylized props के लिए बढ़िया। poly.pizza

Fab (Epic)

Epic का unified marketplace, जो Unreal Marketplace, Quixel Megascans, और Sketchfab store का उत्तराधिकारी है। इसकी खास बात है 1,500+ assets का एक हमेशा-free Megascans starter pack और साथ में हर दो हफ्ते में एक बदलता free drop। पूरी Megascans library अब paid है। हर listing पर license जाँचें। fab.com

AI से models generate करें

2026 तक, एक model generate करना उसे ढूँढने से तेज़ हो सकता है। Meshy और Tripo जैसे tools text या एक image को एक textured 3D mesh में बदल देते हैं, और Hunyuan3D और TRELLIS.2 जैसे open models आपको self-host करने देते हैं। ज़्यादातर hosted tools commercial rights को एक paid plan के पीछे रखते हैं, इसलिए terms जाँच लें। पूरी जानकारी के लिए हमारी games के लिए सबसे अच्छे AI asset generators guide देखें, और ध्यान दें कि Cinevva में एक built-in 3D Model Generator है जो एक photo या text prompt को एक model में बदल देता है।

Licenses 30 सेकंड में

• CC0: public domain। Commercial इस्तेमाल करें, बदलें, कोई attribution नहीं। सबसे सुरक्षित विकल्प।
• CC-BY: free commercial इस्तेमाल, पर आपको creator को credit देना होगा।
• Royalty-Free: एक बार भुगतान करें (या free), बिना per-use fees के इस्तेमाल करें, पर आप raw files दोबारा नहीं बेच सकते।
• CC-BY-NC / Editorial: commercial इस्तेमाल नहीं। जो games आप बेचेंगे, उनके लिए इनसे बचें।

शक हो तो CC0 को प्राथमिकता दें। पूरी जानकारी के लिए हमारी game asset licenses guide देखें।

आम सवाल

Games के लिए free 3D models कहाँ मिलेंगे?

Kenney, Quaternius, और Poly Haven शुरुआत करने की सबसे अच्छी जगहें हैं, सब CC0 हैं इसलिए आप इन्हें बिना किसी attribution के commercial तौर पर इस्तेमाल कर सकते हैं। ज़्यादा variety के लिए, Sketchfab पर mixed licenses के तहत लाखों models हैं, और Poly Pizza archived Google Poly catalog होस्ट करता है। ship करने से पहले हमेशा हर model की license जाँच लें।

3D models के लिए CC0 का क्या मतलब है?

CC0 का मतलब है कि model public domain में है: आप इसे commercial games में इस्तेमाल कर सकते हैं, बदल सकते हैं, और आपको creator को credit देने की ज़रूरत नहीं है। यह सबसे उदार और सबसे कम जोखिम वाली license है। Kenney, Quaternius, Poly Haven, और AmbientCG game assets के मुख्य CC0 sources हैं।

क्या free 3D models commercial games के लिए ठीक हैं?

ज़्यादातर हैं, पर यह license पर निर्भर करता है। CC0 assets हमेशा सुरक्षित हैं। CC-BY में creator को credit देना ज़रूरी है। CC-BY-NC और सिर्फ-Editorial models उन games में इस्तेमाल नहीं किए जा सकते जो आप बेचते हैं। हर model की license जाँचें, और अपने credits में attribution की शर्तों से बचने के लिए CC0 को प्राथमिकता दें।

क्या मैं इसके बजाय AI से 3D models generate कर सकता हूँ?

हाँ। Meshy और Tripo जैसे tools text या images से textured meshes बनाते हैं, और Hunyuan3D और TRELLIS.2 जैसे open models self-host किए जा सकते हैं। Hosted tools पर commercial rights के लिए आमतौर पर एक paid plan चाहिए, इसलिए terms की पुष्टि कर लें। सही free model ढूँढने से AI generation लगातार तेज़ होती जा रही है।

संबंधित

• Free Game Assets कहाँ मिलेंगे — पूरी 20+ source guide
• Sketchfab vs Poly Haven vs Kenney — तीन टॉप sources आमने-सामने
• Games के लिए सबसे अच्छे AI Asset Generators — ढूँढने के बजाय generate करें
• Game Asset Licenses समझाई गईं — CC0, CC-BY, और बाकी सब
• Games के लिए Free Sound Effects और Music — audio वाला पहलू

आखिरी बार अपडेट किया गया: जून 2026.

एक game कैसा महसूस होता है, उसका आधा हिस्सा audio होता है, और इसे पाने के लिए आपको budget की ज़रूरत नहीं। sound effects और music दोनों के लिए बढ़िया free sources मौजूद हैं, लेकिन उनकी licenses में काफ़ी फ़र्क होता है, और कुछ मशहूर sites सिर्फ़ non-commercial हैं, जो चुपचाप उस game को डुबो सकती हैं जिसे आप बेचना चाहते हैं। यहाँ बताया गया है कि 2026 में कहाँ देखें और आप असल में क्या ship कर सकते हैं।

सबसे सुरक्षित CC0 विकल्प (कोई attribution नहीं, commercial के लिए सुरक्षित)

• Kenney audio — पूरी तरह CC0, कोई attribution नहीं, commercial OK। साफ़ game-ready UI clicks, impacts, और retro/8-bit SFX। सबसे बढ़िया विकल्पों में से एक। kenney.nl
• Pixabay Music — Pixabay Content License के तहत free, commercial use, कोई attribution नहीं। बिना किसी झंझट के अच्छा background music और loops। (आप अकेली file को दोबारा नहीं बेच सकते, लेकिन उसे अपनी game में इस्तेमाल करना ठीक है।) pixabay.com
• Sonniss GDC Game Audio bundle — हर साल जारी होता है, commercial use के लिए royalty-free, कोई attribution नहीं, कई साल के archive में professional SFX के सैकड़ों गीगाबाइट। (एक पाबंदी: कोई AI/ML training नहीं।) sonniss.com
• Freesound (CC0 filter) और OpenGameArt (CC0 items) — दोनों CC0 content होस्ट करते हैं; उसके लिए filter करें और आप सुरक्षित हैं।

Sound effects

Freesound

सबसे बड़ी free SFX library, जिसमें लाखों sounds हैं। Licenses हर sound के हिसाब से होती हैं (करीब 72% CC0 हैं, बाकी CC-BY या CC-BY-NC), इसलिए हर file जाँच लें: CC0 को किसी credit की ज़रूरत नहीं, CC-BY को attribution चाहिए। खास एक-बार के effects और field recordings के लिए सबसे अच्छा। freesound.org

Sonniss और Kenney

बड़ी मात्रा के लिए, Sonniss का GDC bundle आपको साफ़ royalty-free license के साथ studio-grade SFX देता है। बिना किसी attribution के तेज़, एक जैसे game sounds के लिए, Kenney के CC0 audio packs बिल्कुल सही हैं। इन दोनों से आप एक game के ज़्यादातर soundscape को सुरक्षित तरीके से कवर कर सकते हैं।

ZapSplat

freemium model पर एक बड़ी SFX library। free tier personal और commercial use के लिए unlimited है लेकिन "ZapSplat" का credit देना ज़रूरी है; कुछ sounds CC0 या CC-BY हैं। paid Gold tier attribution हटा देता है और WAV खोल देता है। जब आप credit शामिल कर सकते हों तब अच्छा। zapsplat.com

Music

Incompetech (Kevin MacLeod)

CC-BY 4.0 के तहत 2,000+ पूरे music tracks, free अगर आप ज़रूरी attribution line शामिल करें ("Music by Kevin MacLeod... Licensed under Creative Commons: By Attribution 4.0")। हर track के लिए no-attribution license खरीदी जा सकती है। कई तरह के moods में पूरे background tracks के लिए सबसे अच्छा। incompetech.com

Pixabay Music और Uppbeat

Pixabay Music बिना झंझट वाला विकल्प है: free, commercial, कोई attribution नहीं। Uppbeat freemium है, जिसमें एक free tier (10 downloads/महीना, attribution ज़रूरी, सीमित commercial use) और एक paid tier है जो इन पाबंदियों को हटा देता है, इसलिए किसी shipped commercial game के लिए यह तब तक कमज़ोर है जब तक आप upgrade न करें। uppbeat.io

Free Music Archive और OpenGameArt

FMA के पास एक बड़ा cross-genre catalog है, लेकिन licenses में काफ़ी फ़र्क है (कई non-commercial हैं), इसलिए हर track ध्यान से जाँचें। OpenGameArt के पास CC0, CC-BY, या GPL के तहत indie/RPG music और chiptune है (GPL audio कानूनी तौर पर उलझन भरा है, इसलिए बाकी को तरजीह दें)। freemusicarchive.org

License के जाल से बचें

दो मशहूर sources commercial games के लिए सुरक्षित नहीं हैं:

• BBC Sound Effects archive free है लेकिन इसकी RemArc license सिर्फ़ non-commercial है। इसे prototypes और student projects के लिए इस्तेमाल करें, उन games के लिए नहीं जिन्हें आप बेचते हैं।
• Internet Archive का audio हर item के हिसाब से बहुत अलग होता है, कुछ बिना rightsholder की मंज़ूरी के अपलोड किए गए हैं। हर item पर rights field जाँचें; यहाँ यह सबसे ज़्यादा जोखिम वाला source है।

AI से audio generate करें

आप SFX और music generate भी कर सकते हैं। Stable Audio (जिसमें एक अलग open sound-effects model शामिल है) और ACE-Step जैसे open models commercial-friendly licenses के साथ sound और music दोनों को कवर करते हैं, जबकि ElevenLabs सबसे मज़बूत hosted विकल्प है (paid plans पर commercial rights)। हमारी open generative AI models गाइड इन्हें कवर करती है, और Cinevva में music generation पहले से मौजूद है।

License त्वरित संदर्भ

आम सवाल

Games के लिए free sound effects कहाँ से मिल सकते हैं?

Freesound के पास सबसे बड़ी library है (licenses हर sound के हिसाब से अलग, ज़्यादातर CC0), Kenney बिना किसी attribution के पूरी तरह CC0 audio packs देता है, और Sonniss GDC bundle आपको बड़ी मात्रा में professional royalty-free SFX देता है। commercial games के लिए, CC0 या साफ़ तौर पर royalty-free sources को तरजीह दें और हर file की license जाँचें।

Games के लिए सबसे अच्छा free music कौन सा है?

बिना attribution वाले music के लिए, Pixabay Music सबसे आसान commercial-safe विकल्प है। Incompetech CC-BY के तहत 2,000+ tracks देता है अगर आप credit line शामिल करें। Free Music Archive में बहुत विविधता है लेकिन मिली-जुली licenses हैं, इसलिए हर track जाँचें। commercial games के लिए BBC Sound Effects से बचें, क्योंकि इसकी license सिर्फ़ non-commercial है।

क्या मुझे free game audio का credit देना होगा?

यह license पर निर्भर करता है। CC0 और Pixabay-licensed audio को किसी credit की ज़रूरत नहीं। CC-BY (जैसे Incompetech) और free-tier ZapSplat या Uppbeat के लिए attribution ज़रूरी है। CC-BY-NC और BBC RemArc license commercial use को पूरी तरह मना करती हैं। अपनी game में attribution की ज़रूरतों से बचने के लिए CC0 को तरजीह दें।

क्या मैं game sound और music generate करने के लिए AI इस्तेमाल कर सकता हूँ?

हाँ। Stable Audio (एक अलग sound-effects model के साथ) और ACE-Step जैसे open models commercial-friendly licenses के साथ audio generate करते हैं, और ElevenLabs paid plans पर commercial rights के साथ एक मज़बूत hosted विकल्प है। commercial तौर पर कुछ भी ship करने से पहले model की output-rights terms की पुष्टि कर लें।

संबंधित

• Free Game Assets कहाँ मिलें — पूरी asset गाइड
• Games के लिए सबसे अच्छी Free 3D Model Sites — visual पक्ष
• Game Asset Licenses समझाई गईं — CC0, CC-BY, royalty-free
• Games के लिए सबसे अच्छे Open-Source Generative AI Models — AI audio generation
• Tone.js game audio — browser में audio चलाना

आख़िरी बार अपडेट किया गया: जून 2026.

itch.io पर अपलोड करना आसान है। खेला जाना ही मुश्किल हिस्सा है। itch.io आपको वैसे audience नहीं थमा देता जैसा कोई बड़ा portal दे सकता है, इसलिए प्लेज़ एक मज़बूत पेज, एक खेलने लायक web build, devlogs, jams, और उस ट्रैफ़िक से आते हैं जो आप खुद लाते हैं। यहाँ बताया गया है कि 2026 में असल में क्या फ़र्क डालता है, और यह इस बात पर टिका है कि itch.io का discovery सच में कैसे काम करता है।

itch.io का discovery असल में कैसे काम करता है

अपनी मेहनत को सही दिशा देने के लिए कुछ बातें जान लें:

• Popular sort एक अपारदर्शी algorithm है जो पुरानी और हाल की गतिविधि को मिलाता है, और हाल की गतिविधि को ज़्यादा वज़न देता है। पक्के तौर पर इसमें organic views, downloads, और plays शामिल हैं। इनमें से किसी को भी नकली बनाने पर आप delist हो जाते हैं।
• Most Recent आपको पहली बार पब्लिश करते समय एक बार जगह देता है; आप republish करके इसे दोबारा नहीं छेड़ सकते (itch आपकी publish date नहीं बदलेगा)।
• फ्रंट पेज इंसानों द्वारा क्यूरेट किया जाता है, स्टाफ़ इसे हाथ से चुनता है, यह algorithmic नहीं है। आप जुगाड़ से इस पर नहीं पहुँच सकते, लेकिन एक बढ़िया पेज और असली traction आपकी संभावनाएँ बढ़ाते हैं।
• इंडेक्स होने के लिए आपका पेज public होना चाहिए, उसमें एक cover image होना चाहिए, और वह खेलने या डाउनलोड करने लायक होना चाहिए। खाली placeholder पेज इंडेक्स नहीं होते, और नए seller अकाउंट एक छोटे review queue से गुज़रते हैं।

व्यावहारिक निचोड़ यह है: itch असली, शुरुआत में ही जमी हुई गतिविधि और एक पूरे पेज को इनाम देता है। यह तिकड़मों को इनाम नहीं देता।

इसे browser में खेलने लायक बनाएँ

यह पेज पर किया जाने वाला सबसे असरदार कदम है। एक HTML5 build अपलोड करें (एक ZIP जिसमें index.html हो) ताकि लोग डाउनलोड करने के बजाय तुरंत खेल सकें। Browser में खेलने लायक गेम download-only गेम की तुलना में कहीं ज़्यादा engagement पाते हैं, क्योंकि इसमें कोई रुकावट नहीं होती; itch के फ़ाउंडर ने कहीं ज़्यादा conversion rate की बात कही है, और analyst डेटा browser गेम को लगभग 3x engagement पर रखता है, जहाँ अक्सर आधे page views प्लेज़ में बदल जाते हैं। अगर आपका engine web पर export कर सकता है, तो कर दें।

पेज को दुरुस्त करें

• Cover image: ज़रूरी है, सुझाया गया साइज़ 630x500। यह आपके पेज का सबसे अहम ग्राफ़िक है, और animated GIF cover समर्थित हैं और इनकी सलाह भी दी जाती है। ऐसी movement से शुरुआत करें जो गेम का hook दिखाए।
• Screenshots और एक trailer/GIF: itch video embeds (YouTube, Vimeo) को screenshots के ऊपर दिखाता है, और गेम के लिए तो ख़ासकर इसकी सलाह देता है। बताएँ नहीं, दिखाएँ।
• छोटा description: यह हर जगह listings में दिखता है, इसलिए इसे एक साफ़, ख़ास hook बनाएँ।

Tags और metadata

अपने खुद के tags गढ़ने के बजाय सुझाए गए tags इस्तेमाल करें, synonyms से बचें, और tag-stuffing न करें, जिससे आप browse से हटा दिए जाते हैं। आप 10 tags तक और एक genre इस्तेमाल कर सकते हैं। किसी platform (Windows/Mac/Linux) पर तभी टिक करें जब आपके पास उसके लिए एक जाँचा हुआ build हो; ग़लत वर्गीकरण करने पर आप delist हो जाते हैं।

Devlogs का इस्तेमाल करें

एक devlog पब्लिश करना आपके सभी followers के feeds और साइट-भर के devlog feed में जाता है, जो आपके followers से भी आगे तक पहुँचता है। जब आप कोई नया project रिलीज़ करते हैं या किसी को sale पर लगाते हैं, तब भी followers को सूचना मिलती है। तो devlogs पोस्ट करने से followers बढ़ते हैं, और उन followers को आपकी अगली launch पर पिंग मिलती है। devlogs को एक बार-बार काम आने वाले ट्रैफ़िक और audience बनाने के औज़ार की तरह लें, न कि कोई बाद में सोचने वाली चीज़।

Game jams में हिस्सा लें (असली discovery engine)

itch.io पर organic discovery का सबसे बड़ा चालक jams ही हैं, इनके लिए लाखों गेम बनाए जाते हैं। एक jam आपको एक बना-बनाया audience, एक deadline, और एक reciprocity mechanic देता है: अगर आप दूसरी entries को rate और comment करते हैं (और अपनी खुद की entry जमा कर चुके हों), तो आपके comments के नीचे आपके गेम का एक link अपने-आप जुड़ जाता है, जो प्लेज़ को वापस आप तक खींचता है। GMTK जैसे बड़े jams में हज़ारों की तादाद में लोग हिस्सा लेते हैं। jams जादुई तरीके से Popular algorithm को बढ़ावा नहीं देंगे, लेकिन जब और कुछ काम न कर रहा हो, तब ये आपके गेम पर असली नज़रें ले आते हैं।

प्लेज़ के लिए pricing

itch की pricing हमेशा pay-what-you-want होती है: एक तय क़ीमत बस एक न्यूनतम होती है, और ख़रीदार उससे ज़्यादा दे सकते हैं (ख़र्च किए गए पैसे का लगभग 30% न्यूनतम से ऊपर का अतिरिक्त होता है)। ज़्यादा से ज़्यादा प्लेज़ के लिए, free या pay-what-you-want सारी रुकावट हटा देता है और फिर भी fans को tip देने देता है। ध्यान रखें कि HTML5 गेम payments सिर्फ़ donations के रूप में ले सकते हैं। हमेशा चलने वाली sales से बचें, जिन्हें itch सच में sale पर न मानते हुए deindex कर सकता है।

अपना खुद का ट्रैफ़िक लाएँ (जहाँ से ज़्यादातर प्लेज़ आते हैं)

itch featured गेम को तेज़ी से बदलता रहता है और Steam की तरह discovery को टिकाए नहीं रखता, इसलिए असली प्लेज़ बाहरी ट्रैफ़िक से आते हैं:

• Streamers और YouTubers सबसे असरदार channel हैं; एक अकेला creator महीनों की दूसरी मेहनत से ज़्यादा installs ला सकता है, और वे मुफ़्त demos के लिए itch को सक्रिय रूप से खंगालते हैं।
• असल gameplay clips का short-form video (TikTok, Reels, Shorts) अब indie virality का एक मुख्य चालक है।
• Reddit (r/IndieGaming, r/playmygame, और ऐसे ही), जहाँ community posts और self-promo का लगभग 9-से-1 का नियम मानें।
• playtesters और retention के लिए Discord, और GIFs के साथ X #screenshotsaturday।

बिना बजट वाली व्यापक रणनीति के लिए, देखें बिना बजट के indie गेम को कैसे promote करें।

आम ग़लतियाँ

जब web build मुमकिन हो तब download-only रखना, कमज़ोर या ग़ायब cover, कोई trailer या GIF न होना, पतले descriptions, ख़राब या ठूँसे हुए tags, पब्लिश करके चुप हो जाना (कोई devlogs नहीं), यह उम्मीद करना कि algorithm या featuring काम कर देगा, कोई demo न होना, और metrics को नकली बनाना (जिससे आप delist हो जाते हैं)। इन्हें पहले ठीक करें; ये मुफ़्त हैं।

आम सवाल

itch.io पर मैं ज़्यादा प्लेज़ कैसे पाऊँ?

एक browser में खेलने लायक HTML5 build अपलोड करें (यह downloads से कहीं ज़्यादा engagement पाता है), एक animated cover और trailer के साथ एक मज़बूत पेज बनाएँ, सटीक सुझाए गए tags इस्तेमाल करें, followers तक पहुँचने के लिए devlogs पोस्ट करें, बने-बनाए discovery के लिए game jams में हिस्सा लें, और streamers, short-form video, और communities से बाहरी ट्रैफ़िक लाएँ। itch असली गतिविधि और एक पूरे पेज को इनाम देता है, तिकड़मों को नहीं।

क्या itch.io आपके गेम को आपके लिए promote करता है?

ज़्यादा नहीं। फ्रंट पेज को स्टाफ़ हाथ से क्यूरेट करता है, और Popular sort असली हाल की गतिविधि के आधार पर तेज़ी से बदलता रहता है। itch आपको औज़ार और एक बुनियादी audience देता है, लेकिन टिकी हुई discovery आपके किए से आती है: एक खेलने लायक build, devlogs, jams, और वह ट्रैफ़िक जो आप streamers, video, और communities से लाते हैं।

क्या itch.io पर web गेम downloads से ज़्यादा प्लेज़ पाते हैं?

हाँ, काफ़ी ज़्यादा। Browser में खेलने लायक गेम डाउनलोड करने की रुकावट हटा देते हैं, और डेटा बताता है कि इनमें download-only गेम से लगभग 3x engagement होता है, जहाँ page views का एक बड़ा हिस्सा प्लेज़ में बदलता है। अगर आपका engine HTML5 पर export करता है, तो एक खेलने लायक web build पब्लिश करना ज़्यादा प्लेज़ के लिए अकेला सबसे अच्छा कदम है।

क्या प्लेज़ पाने के लिए game jams फ़ायदेमंद हैं?

बहुत। itch.io पर organic discovery का सबसे बड़ा चालक jams ही हैं: ये आपको एक बना-बनाया audience और एक deadline देते हैं, और दूसरी entries को rate करने पर आपका गेम अपने-आप वापस link हो जाता है, जिससे प्लेज़ खिंचकर आते हैं। ये सीधे algorithm को बढ़ावा नहीं देंगे, लेकिन जब आपके पास और कोई audience न हो, तब ये आपके गेम पर असली players ले आते हैं।

संबंधित

• itch.io पर अपना गेम कैसे लॉन्च करें — सेटअप की बुनियादी बातें
• 2026 में web गेम पब्लिश करने की सबसे अच्छी जगहें — itch.io बनाम portals
• बिना बजट के indie गेम को कैसे promote करें — व्यापक रणनीति
• Game Jams और Hackathons — किन jams में हिस्सा लेना है यह चुनना
• Steam Next Fest रणनीति — अगर आप इसे Steam पर भी ले जाएँ

आखिरी बार अपडेट किया गया: जून 2026.

कुछ साल पहले तक गेम बनाने का मतलब था कि कुछ भी खेलने लायक हाथ आने से पहले आपको एक engine, एक प्रोग्रामिंग भाषा और एक आर्ट पाइपलाइन सीखनी पड़ती थी। 2026 में आप सादे अंग्रेजी में एक गेम का वर्णन कर सकते हैं और मिनटों में एक काम करता वर्जन पा सकते हैं। रचनात्मक फैसले अब भी आप ही करते हैं, लेकिन AI बाकी सब संभाल लेता है: movement, collisions, physics, placeholder आर्ट और साउंड।

यह गाइड बिना कोडिंग के पूरी प्रक्रिया समझाती है, आपके पहले prompt से लेकर पब्लिश किए गए गेम तक। उदाहरण एक browser-आधारित AI game creator का उपयोग करते हैं, लेकिन यह वर्कफ्लो ज्यादातर prompt-to-game tools पर लागू होता है।

आपको क्या चाहिए

ज्यादा कुछ नहीं। एक browser, एक आइडिया और एक tool। आपको कोई engine इंस्टॉल करने, GPU या कोई आर्ट की जरूरत नहीं। अगर आप पहले tool चुनना चाहते हैं, तो हमारी AI गेम जनरेटर की तुलना देखें; और अगर आप बस शुरू करना चाहते हैं, तो अभी एक creator खोलकर एक आइडिया टाइप कर सकते हैं।

स्टेप 1: एक साफ, छोटे आइडिया से शुरू करें

शुरुआती लोग सबसे आम गलती यही करते हैं कि "multiplayer वाला एक open-world RPG" के लिए prompt देते हैं। AI tools सबसे अच्छे नतीजे एक छोटे, खास core से बनाते हैं जिसे आप बाद में बढ़ा सकते हैं। तीन चीजें बताएं:

• गेम किस तरह का है। Platformer, racer, shooter, puzzle, survival, cozy sim।
• एक चीज जो इसे आपका बनाती है। एक glow, नियमों में एक मोड़, कोई सेटिंग।
• एक लक्ष्य। प्लेयर क्या करने की कोशिश कर रहा है।

"एक first-person parkour गेम जहां आप तैरते हुए द्वीपों पर एक टाइमर के खिलाफ दौड़ते हैं" एक "मजेदार 3D एडवेंचर" से कहीं बेहतर शुरुआती prompt है। पहला AI को बनाने के लिए एक आकार देता है; दूसरा उसे अंदाजा लगाने पर मजबूर करता है।

स्टेप 2: अपना पहला prompt लिखें

इसे एक या दो वाक्य तक रखें। आप कोई स्पेक नहीं लिख रहे, आप एक बातचीत शुरू कर रहे हैं। एक अच्छा पहला prompt genre, लक्ष्य और अहसास बताता है:

एक top-down zombie survival गेम बनाओ जिसमें एक flashlight हो जो सिर्फ एक पतली cone को रोशन करे, सीमित ammo हो, और waves जो और मुश्किल होती जाएं।

फिर tool को बनाने दें। आपको एक खेलने लायक पहला वर्जन मिलेगा, अक्सर अधूरा, और यही आप चाहते हैं, क्योंकि असली काम iteration है। अगर एक खाली बॉक्स डराने वाला लगे, तो किसी तैयार prompt से शुरू करें और एक शब्द बदल दें।

स्टेप 3: उससे बात करके iterate करें

असल में गेम यहीं बनते हैं। पहला वर्जन खेलें, वह एक चीज ढूंढें जो आपको सबसे ज्यादा खटकती है, और सिर्फ उसी एक बदलाव के लिए कहें। छोटी, खास मांगें बड़ी अस्पष्ट मांगों से बेहतर होती हैं:

• "प्लेयर को तेज चलाओ और ऊंचा कूदने दो।"
• "दुश्मन बहुत आक्रामक हैं, उन्हें धीमा करो और उनकी health कम करो।"
• "ऊपर दाईं ओर एक score counter और एक game-over स्क्रीन जोड़ो।"

एक चीज बदलें, खेलें, दोहराएं। अगर किसी बदलाव से हालत बिगड़े, तो उससे undo या revert करने के लिए कहें। इसे कोडिंग नहीं, डायरेक्टिंग की तरह मानें: आप बताते हैं कि आप कैसा नतीजा चाहते हैं और नतीजे को परखते हैं।

स्टेप 4: जो assets चाहिए वे जनरेट करें

आधुनिक AI game tools मांग पर आर्ट और ऑडियो जनरेट करते हैं, इसलिए आप ग्रे बॉक्स में अटके नहीं रहते। tool के हिसाब से आप 3D models, textures, sprites, म्यूजिक और sound effects मांग सकते हैं, या बिल्ट-इन फ्री asset लाइब्रेरी से ले सकते हैं। जो मूड के हिसाब से फिट हो वह मांगें: "प्लेयर को एक low-poly रोबोट model दो," "उत्साह भरा synth म्यूजिक जोड़ो," "एक रेगिस्तानी skybox इस्तेमाल करो।" अगर आपके tool में CC0 asset लाइब्रेरी है, तो जो कुछ भी आप पब्लिश करने की योजना बना रहे हैं उसके लिए वह सबसे सुरक्षित स्रोत है। हमारी फ्री गेम assets गाइड बताती है कि ये कहां से आते हैं और लाइसेंसिंग कैसे काम करती है।

स्टेप 5: अहसास को निखारें

एक टेक डेमो और एक गेम के बीच का फर्क अहसास है। जब core loop काम करने लगे, तो अपने iterations उन चीजों पर लगाएं जो प्लेयर असल में नोटिस करते हैं: फुर्तीले controls, कुछ होने पर साफ फीडबैक, एक दिखने वाला लक्ष्य, और एक जीत या हार की स्थिति। एक टाइटल स्क्रीन, एक restart बटन, अहम एक्शन पर साउंड, और एक कठिनाई का वक्र मांगें। यही छोटी बातें गेम को पूरा हुआ महसूस कराती हैं।

स्टेप 6: पब्लिश और शेयर करें

जब यह खेलने लायक हो जाए, तो इसे पब्लिश करें। Browser-आधारित tools एक ही क्लिक में आपको एक शेयर करने लायक लिंक देते हैं, जो फीडबैक पाने का सबसे तेज तरीका है। इसे दोस्तों के साथ शेयर करें, जहां आपकी ऑडियंस जुटती है वहां पोस्ट करें, और देखें कि लोग कहां अटकते हैं या छोड़ देते हैं। वह फीडबैक ही आपके iteration का अगला दौर है। अगर आप आगे जाना चाहते हैं, तो हमारी itch.io लॉन्च गाइड एक web गेम को व्यापक ऑडियंस तक पहुंचाना समझाती है।

टिप्स जो AI गेम-मेकिंग को कारगर बनाते हैं

• छोटा रहें, फिर बढ़ें। फीचर जोड़ने से पहले एक छोटा पूरा गेम शिप करें। एक तैयार छोटा गेम एक अधूरे बड़े गेम से बेहतर होता है।
• एक बार में एक बदलाव। एक साथ बंडल की गई मांगें AI को उलझा देती हैं और यह बताना मुश्किल कर देती हैं कि क्या काम आया।
• नतीजे बताएं, तरीका नहीं। कहें "jump फ्लोटी लगता है, इसे और चुस्त बनाओ," न कि "gravity को 20 पर सेट करो।"
• एक भरोसेमंद वर्जन संभालकर रखें। किसी बड़े बदलाव से पहले नोट कर लें कि मौजूदा हालत काम करती है ताकि आप उस पर लौट सकें।
• उबाऊ हिस्सों के लिए AI का इस्तेमाल करें। boilerplate और वेरिएशन इसे संभालने दें ताकि आपका वक्त उन फैसलों पर लगे जो गेम को आपका बनाते हैं।

AI किसमें अच्छा है, और किसमें नहीं

AI आपको शून्य से एक खेलने लायक prototype तक तेजी से पहुंचाने, placeholder और यहां तक कि फाइनल assets जनरेट करने, और एक गेम की मशीनी नलसाजी संभालने में सचमुच अच्छा है। यह बड़े, systems-heavy डिजाइनों, बारीक बैलेंसिंग, और किसी भी ऐसी चीज में कमजोर है जिसके लिए एक सुसंगत दीर्घकालिक दृष्टि चाहिए, जो अब भी आपका काम है। 2026 की सही उम्मीद: AI एक वीकेंड की सेटअप को एक दोपहर में समेट देता है, और भरोसेमंद नतीजे फैले हुए गेमों की बजाय छोटे और मझोले गेमों के आसपास जमा होते हैं।

आम सवाल

क्या मैं सचमुच बिना किसी कोडिंग अनुभव के गेम बना सकता हूं?

हां। 2026 में prompt-to-game tools सादे-अंग्रेजी विवरण से आपके लिए कोड, आर्ट और logic जनरेट करते हैं, तो आप बिना कोई कोड लिखे या पढ़े एक खेलने लायक गेम बना और पब्लिश कर सकते हैं। आप जो चाहते हैं उसका वर्णन करके और नतीजों को निखारकर गेम को डायरेक्ट करते हैं।

AI से गेम बनाने में कितना समय लगता है?

एक सादा, खेलने लायक गेम मिनटों से लेकर एक घंटे में बन सकता है। एक छोटा लेकिन निखरा हुआ गेम, आर्ट, साउंड, menus और कठिनाई के वक्र के साथ, iteration की एक दोपहर से एक वीकेंड जैसा होता है। बड़े या ज्यादा जटिल गेमों में अब भी ज्यादा समय लगता है, क्योंकि काम सेटअप से हटकर डिजाइन और निखार पर आ जाता है।

AI किस तरह के गेम बना सकता है?

AI छोटे और कैज़ुअल गेम सबसे अच्छे संभालता है: platformers, runners, arcade shooters, puzzles, racers, survival, और cozy sims। Browser tools 2D और 3D दोनों कर सकते हैं, हालांकि 2D आमतौर पर ज्यादा भरोसेमंद होता है। बड़े systems-heavy गेम जैसे बड़े RPGs या strategy titles साफ-सुथरे तरीके से जनरेट करना अब भी मुश्किल है और इन्हें काफी मानवीय दिशा-निर्देश चाहिए।

क्या AI से गेम बनाने के लिए मुझे पैसे देने होंगे?

ज्यादातर tools का एक फ्री टियर होता है जो एक गेम बनाने और आजमाने के लिए काफी है। आप आमतौर पर तब पैसे देते हैं जब आपको भारी जनरेशन, commercial अधिकार, या export चाहिए। हमारी AI गेम जनरेटर तुलना फ्री टियर और कीमतें साथ-साथ दिखाती है।

क्या मैं AI से बनाया गया गेम बेच सकता हूं?

अक्सर हां, लेकिन दो चीजें जांचें: tool की commercial शर्तें (कुछ commercial इस्तेमाल को एक paid प्लान के पीछे रखते हैं) और किसी भी जनरेट किए गए या इंपोर्ट किए गए assets का लाइसेंस। कई platforms यह भी मांगते हैं कि आप AI-जनरेटेड सामग्री का खुलासा करें। सुरक्षित रहने के लिए CC0 assets और tool के commercial टियर पर टिके रहें।

संबंधित

• 2026 में सबसे अच्छे AI गेम जनरेटर — पहले सही tool चुनें
• बिना कोडिंग के 3D browser गेम कैसे बनाएं — 3D-केंद्रित पूरी प्रक्रिया
• Vibe Coding गेम्स: यह क्या है और कैसे शुरू करें — prompt-चालित बनाने के पीछे की सोच
• AI गेम Prompts जो आप एक क्लिक में बना सकते हैं — शुरुआती बिंदु
• फ्री गेम assets कहां मिलें — आपके गेम के लिए आर्ट और ऑडियो
• itch.io पर अपना गेम कैसे लॉन्च करें — प्लेयर पाना

आखिरी अपडेट: जून 2026.

मल्टीप्लेयर वह फीचर है जो एक छोटे गेम को फैला देता है, और 2026 में आप इसे अपना खुद का data center चलाए बिना एक browser गेम में जोड़ सकते हैं। मुश्किल हिस्सा players को जोड़ना नहीं है, बल्कि गेम को sync में और fair रखना है। यह गाइड उन चुनावों को कवर करती है जो मायने रखते हैं (transport, server model, netcode) और वे टूल जो इसे संभालने लायक बनाते हैं, फिर आपको एक समझदारी भरा शुरुआती स्टैक देती है।

पहले, इसका scope ईमानदारी से तय करें

मल्टीप्लेयर की कठिनाई इस बात के साथ तेजी से बढ़ती है कि आपका गेम कितना तेज और competitive है।

• आसान: turn-based गेम्स (cards, board games), 2-8 के छोटे rooms, shared cursors, lobbies, chat, casual co-op। सादे WebSockets या कोई zero-backend टूल काफी है।
• मुश्किल: तेज real-time action (shooters, .io movement), बहुत सारे एक साथ खेलने वाले players, और कोई भी ऐसी competitive चीज जहां cheating मायने रखती है। इनके लिए एक authoritative server, prediction और सावधानी से बनाया गया netcode चाहिए।

आसान बकेट से शुरुआत करें। एक चलता हुआ turn-based या छोटे-room वाला गेम आपको मुश्किल समस्याएं उठाने से पहले पूरा pipeline सिखा देता है।

Transport: डेटा कैसे सफर करता है

• WebSockets व्यावहारिक default हैं। TCP-based, bidirectional, परिपक्व, और हर जगह supported। इसकी एकमात्र कमजोरी head-of-line blocking है: एक dropped packet उसके पीछे की हर चीज को रोक देता है, जो तेज action गेम्स को नुकसान पहुंचाता है। ज्यादातर गेम्स के लिए, WebSockets शिप करें।
• WebRTC UDP जैसे data channels लाता है (कोई head-of-line blocking नहीं), तेज action या peer-to-peer के लिए अच्छा, लेकिन इसे set up करना कहीं ज्यादा जटिल है (signaling, STUN/TURN)। इसे तभी चुनें जब आपको P2P चाहिए या relay server से बचना जरूरी हो।
• WebTransport नया विकल्प है (HTTP/3 + QUIC) जिसमें UDP-शैली के datagrams हैं। चीजें इसी दिशा में जा रही हैं, लेकिन 2026 में browser support अभी भी ठीक हो रहा है, इसलिए आज शिप करने वाले किसी शुरुआती के लिए यह अकेला transport होना सुरक्षित नहीं है।

अंगूठे का नियम: अभी शिप करने के लिए WebSockets, जरूरत पड़ने पर बाद में WebTransport, और P2P या media के लिए WebRTC।

Server model: कौन तय करता है कि क्या हुआ

• Authoritative server: clients inputs भेजते हैं, server simulation चलाता है और result को broadcast करता है। यह किसी भी competitive चीज के लिए standard है क्योंकि server स्वाभाविक anti-cheat सीमा है, आप कभी client पर भरोसा नहीं करते।
• Peer-to-peer: चलाने में सस्ता, लेकिन cheating रोकना मुश्किल है और connectivity नाजुक होती है। casual co-op और छोटे भरोसेमंद lobbies के लिए ठीक है।

एक छोटे गेम के लिए भी, एक authoritative server आपके "source of truth" को सरल रखता है। नीचे दिए गए ज्यादातर टूल इसी model को default करते हैं।

Netcode की बुनियादी बातें (सिर्फ जब आपको जरूरत हो)

तेज real-time गेम्स के लिए, कच्चा state-syncing laggy लगता है। Gabriel Gambetta की क्लासिक सीरीज में अच्छी तरह समझाए गए standard fixes ये हैं:

• Client-side prediction: client server round-trip का इंतजार करने के बजाय आपके input को तुरंत apply कर देता है, इसलिए movement instant महसूस होता है।
• Server reconciliation: जब authoritative state आता है, client अपने pending inputs को फिर से apply करके किसी भी drift को ठीक करता है।
• Entity interpolation: दूसरे players को थोड़ा अतीत में, ज्ञात states के बीच render करें, ताकि उनकी गति smooth हो।
• Lag compensation: server वहां तक rewind करता है जहां target तब था जब shot fire हुआ था, ताकि hits fair तरीके से resolve हों।

इन्हें पहले से मत बनाएं। इन्हें तभी जोड़ें जब movement सच में खराब महसूस हो, जो turn-based या धीमे गेम्स के लिए नहीं होगा।

2026 का टूल परिदृश्य

एक अनुशंसित शुरुआती स्टैक

2026 में एक छोटे real-time browser गेम के लिए:

• Transport: WebSockets (अभी-शिप-करने वाली compatibility)।
• Server model: authoritative, एक छोटे गेम के लिए भी, ताकि cheating और "source of truth" सरल रहें।
• Framework: Colyseus। यह MIT है, self-host करने के लिए मुफ्त है, और आपको rooms, matchmaking, और अपने आप state sync सीधे बॉक्स से देता है, साथ ही एक managed cloud (लगभग $15/माह से) जब आप servers चलाना न चाहें। अगर आप किसी casual गेम के लिए zero backend चाहते हैं, तो Playroom और भी तेज विकल्प है; अगर आप पहले से Cloudflare पर हैं, तो PartyKit या Durable Objects स्वाभाविक रूप से फिट होते हैं।
• Netcode: prediction के बिना शुरू करें। Gambetta-शैली की prediction और interpolation तभी जोड़ें जब movement laggy महसूस हो।

आम सवाल

मल्टीप्लेयर browser गेम बनाने का सबसे आसान तरीका क्या है?

Colyseus जैसे framework या Playroom जैसे zero-backend टूल के जरिए WebSockets का इस्तेमाल करके एक turn-based या छोटे-room वाले गेम से शुरुआत करें। ये आपके लिए rooms, joining और state sync संभालते हैं, इसलिए आप netcode बनाए या अपने खुद के servers चलाए बिना एक चलता हुआ मल्टीप्लेयर गेम शिप कर सकते हैं। तेज real-time action को तब के लिए बचाकर रखें जब आप कुछ सरल शिप कर चुके हों।

मुझे अपने गेम के लिए WebSockets इस्तेमाल करने चाहिए या WebRTC?

ज्यादातर गेम्स के लिए WebSockets: ये सरल, परिपक्व और हर जगह supported हैं। WebRTC सिर्फ तब इस्तेमाल करें जब आपको peer-to-peer connections चाहिए या तेज action के लिए सबसे कम latency चाहिए, क्योंकि इसे set up करना काफी ज्यादा जटिल है। WebTransport एक आशाजनक भविष्य का विकल्प है लेकिन 2026 में इसका browser support अभी भी ठीक हो रहा है।

क्या मुझे मल्टीप्लेयर के लिए अपना खुद का server चाहिए?

जरूरी नहीं। Colyseus Cloud, Playroom, PartyKit और Photon जैसे managed टूल realtime हिस्से को आपके लिए host करते हैं। अगर आपको पूरा control चाहिए तो आप Colyseus या Nakama जैसे open-source frameworks को खुद भी host कर सकते हैं। एक छोटे गेम के लिए, managed service सबसे तेज रास्ता है और अक्सर शुरू करने के लिए मुफ्त या सस्ता होता है।

मल्टीप्लेयर गेम में cheating कैसे रोकूं?

एक authoritative server इस्तेमाल करें: clients सिर्फ अपने inputs भेजते हैं, और server तय करता है कि असल में क्या होता है, हर चीज को validate करते हुए। गेम के नतीजे के लिए कभी client पर भरोसा न करें। इसीलिए Colyseus, Nakama और Photon जैसे frameworks एक server-authoritative model को default करते हैं, खासकर किसी भी competitive चीज के लिए।

संबंधित

• 2026 के लिए सबसे अच्छे Web Game Engines — वह engine जिस पर आपका मल्टीप्लेयर गेम चलता है
• शुरुआती लोगों के लिए सबसे अच्छे मुफ्त गेम इंजन — कहां से शुरू करें
• WebSocket मल्टीप्लेयर की बुनियादी बातें — एक हाथों-हाथ परिचय
• अपना गेम itch.io पर कैसे launch करें — अपने मल्टीप्लेयर गेम को publish करना

आखिरी बार अपडेट किया गया: जून 2026.

browser में 2D games के लिए, दो इंजन अलग-अलग खूबियों पर आगे हैं: Phaser, सबसे लोकप्रिय HTML5 framework, और Defold, वह इंजन जिसके web builds सबसे छोटे और सबसे तेज़ load होने वाले हैं। ये अलग-अलग developers के लिए ठीक बैठते हैं। चुनने में मदद के लिए यहाँ 2026 की तुलना है।

झटपट फैसला

• सबसे छोटे, सबसे तेज़ load होने वाले web builds और एक polished all-in-one editor: Defold.
• सबसे बड़ी community, सबसे ज़्यादा tutorials, और एक code-first JavaScript framework: Phaser.

दोनों free हैं। असली फैसला workflow (visual editor बनाम code framework), language (Lua बनाम JavaScript), और आपके लिए load-time व community कितने मायने रखते हैं, इस बारे में है।

तुलना

Phaser 4

Phaser सबसे लोकप्रिय HTML5 game framework है, और version 4.0 अप्रैल 2026 में stable रिलीज़ हुआ (4.2 जैसे point releases तेज़ी से इसके बाद आए)। यह WebGL2 renderer का ज़मीन से नया rewrite है जिसमें एक नया node-based architecture है, जबकि जाना-पहचाना v3 API बरकरार है। आप JavaScript या TypeScript लिखते हैं और physics, input, audio, scenes, व asset loading सीधे तैयार मिलते हैं। framework खुद छोटा है (~500 KB), हालाँकि आपका अंतिम size आपके assets पर निर्भर करता है। बड़े फायदे हैं विशाल community, tutorials व examples का ढेर, और यह कि आप standard web code लिख रहे हैं जिस पर आपका पूरा control है। ध्यान दें कि Phaser 4 एक WebGL2 इंजन है, WebGPU नहीं; WebGPU आगे की तैयारी है, कोई शिप हुआ feature नहीं।

Defold

Defold, जो मूल रूप से King (Candy Crush) से आया, छोटे, तेज़ load होने वाले web games के लिए बना है। इसका खाली HTML5 build करीब 1.06 MB का है और यह default रूप से WebAssembly इस्तेमाल करता है, जिससे यह top web games के अध्ययनों में सबसे तेज़ load होने वाले इंजनों में से एक बन जाता है। यह एक पूरे package के रूप में आता है: एक built-in editor, scene tools, और Poki जैसी platforms पर one-click publishing। नवीनतम stable release 1.12.4 है (मई 2026), और यह free है बिना किसी royalty के। बदले में मिलते हैं Phaser से छोटी community और Lua scripting व Defold के component model के इर्द-गिर्द एक सीखने की मशक्कत। यह मुख्यतः एक 2D इंजन है, हालाँकि यह सक्रिय रूप से 3D features जोड़ रहा है।

कैसे चुनें

अगर आप पहले से JavaScript जानते हैं, tutorials और मदद का सबसे बड़ा भंडार चाहते हैं, और अपना खुद का toolchain जोड़ना पसंद करते हैं, तो Phaser चुनें। अगर आप सबसे छोटे, सबसे तेज़ load होने वाले builds, एक polished all-in-one editor, और built-in publishing चाहते हैं, और Lua सीखने में आपको दिक्कत नहीं है, तो Defold चुनें। load-time के लिहाज़ से नाज़ुक mobile web games के लिए Defold के पास एक असली बढ़त है; सीखने और community सपोर्ट के लिए Phaser को हराना मुश्किल है।

PixiJS, Construct, और GDevelop समेत पूरा मैदान चाहते हैं? हमारा 2026 के सबसे अच्छे 2D game engines देखें।

आम सवाल

2D web games के लिए Phaser बेहतर है या Defold?

दोनों शानदार हैं; ये अलग-अलग developers के लिए ठीक बैठते हैं। Phaser एक code-first JavaScript framework है जिसकी सबसे बड़ी community और सबसे ज़्यादा learning material है। Defold एक पूरा इंजन है जिसमें built-in editor और सबसे छोटे, सबसे तेज़ load होने वाले web builds हैं। community और JavaScript के लिए Phaser चुनें, load time और एक all-in-one workflow के लिए Defold।

किसके web builds छोटे और तेज़ load होने वाले हैं?

Defold। इसका खाली HTML5 build करीब 1.06 MB का है और WebAssembly इस्तेमाल करता है, जिससे यह web games के लिए सबसे तेज़ load होने वाले इंजनों में से एक बन जाता है। Phaser का framework करीब 500 KB का है, पर यह एक पूरे build के बजाय एक framework है, और आपका असली size काफ़ी हद तक आपके अपने assets पर निर्भर करता है। load-time के प्रति संवेदनशील games के लिए Defold के पास बढ़त है।

क्या Phaser और Defold WebGPU सपोर्ट करते हैं?

2026 में किसी शिप हुए feature के तौर पर नहीं। Phaser 4 एक WebGL2 rewrite है, जिसमें WebGPU सिर्फ़ आगे की तैयारी के रूप में है। Defold का HTML5 backend WebGL है, जिसमें प्रयोगात्मक WebGPU काम चल रहा है। 2D games के लिए यह शायद ही मायने रखता है; सामान्य 2D rendering के लिए WebGL2 काफ़ी से ज़्यादा है।

क्या Phaser और Defold व्यावसायिक games के लिए free हैं?

हाँ। Phaser MIT license के तहत free है, और Defold free व open-source है, बिना किसी royalty या revenue सीमा के। कोई भी आपसे व्यावसायिक game शिप करने के लिए पैसे नहीं लेता, हालाँकि Phaser एक अलग वैकल्पिक editor product बेचता है।

संबंधित

• 2026 के सबसे अच्छे 2D Game इंजन — पूरा 2D मैदान
• 2026 के सबसे अच्छे Web Game इंजन — 2D और 3D साथ में
• शुरुआती लोगों के लिए सबसे अच्छे Free Game इंजन — कहाँ से शुरू करें
• अपना game itch.io पर कैसे लॉन्च करें — एक तैयार 2D game publish करना

आख़िरी बार अपडेट किया गया: जून 2026.

किसी गेम की मार्केटिंग के लिए आपको विज्ञापन के पैसे की ज़रूरत नहीं है। आपको समय, एक साफ़ hook, और जल्दी शुरुआत करने की ज़रूरत है। 2026 की कड़वी सच्चाई यह है कि समस्या discovery की है, माँग की नहीं: 2024 में Steam पर करीब 19,000 गेम आए, और ज़्यादातर ने कभी ठीक-ठाक बिक्री नहीं देखी। अच्छी बात यह है कि जो चैनल इंडीज़ के लिए काम करते हैं, वे ज़्यादातर मुफ़्त हैं। यहाँ बताया गया है कि उन्हें कैसे इस्तेमाल करें।

Steam पेज से शुरू करें (अगर आप Steam पर हैं)

अगर आपका गेम Steam से जुड़ा है, तो सबसे कीमती मुफ़्त काम जो आप कर सकते हैं वह है जल्दी एक "Coming Soon" पेज लगाना। जिन गेम्स ने इसे लॉन्च से छह या ज़्यादा महीने पहले लगाया, उन्होंने आख़िरी महीने तक रुकने वालों के मुकाबले कहीं ज़्यादा बिक्री देखी। wishlists कभी एक्सपायर नहीं होते, इसलिए जैसे ही आपके पास कुछ screenshots और एक छोटी clip हो, पेज लगा देना चाहिए।

wishlists असल में करते क्या हैं: हर wishlister को लॉन्च पर और छूट पर नोटिफिकेशन मिलता है, जो एक backlog को पहले दिन की बिक्री के उछाल में बदल देता है। ये आख़िरी हफ़्ते में "Popular Upcoming" टैब को भी चलाते हैं। एक मोटा-मोटा टिकाऊ-लॉन्च फ़्लोर करीब 7,000 wishlists है; यह कोई जादुई नंबर नहीं है, इसका बस मतलब है उस हफ़्ते की एक टॉप रिलीज़ बनना। अपने स्टोर पेज को भी ठीक से भरें: सही tags (Steam इन्हीं से categorize करता है) और ज़्यादा supported languages, दोनों बढ़ाते हैं कि Steam आपको कितनी बार सामने लाता है।

Next Fest डेमो लूप

Steam Next Fest सबसे बड़ा मुफ़्त wishlist इवेंट है, लेकिन यह किसी मौजूदा audience को बढ़ाता है, नई audience बनाता नहीं। आपको जितने wishlists मिलते हैं वे उन wishlists के साथ मज़बूती से बढ़ते हैं जिन्हें आप ख़ुद लाते हैं, इसलिए fest से पहले एक audience बनाएँ, फिर उस पर सवार हों। एक अच्छा demo-to-wishlist कन्वर्ज़न करीब 16-20% है।

एक ऐसा गेम बनाएँ जो अपनी मार्केटिंग ख़ुद करे

सबसे बड़ा मार्केटिंग फ़ैसला किसी भी मार्केटिंग से पहले होता है: आपका genre और concept। एक high-concept गेम अपने पहले screenshot से ही फैलता है, और लोगों की दिलचस्पी जगाने के लिए बस एक-दो वाक्य चाहिए होते हैं। अगर आप clip के कुछ सेकंड में यह नहीं दिखा सकते कि आपका गेम दिलचस्प क्यों है, तो मार्केट उसे स्क्रॉल करके आगे बढ़ जाएगा। इसलिए एक hook के साथ शुरू करें: trailers और clips को पहले ही कुछ सेकंड में दिलचस्प चीज़ तक पहुँचना चाहिए, और फ़ीचर की लिस्ट के बजाय पहले genre, फिर hook, फिर content दिखाना चाहिए।

2026 में काम करने वाले मुफ़्त चैनल

• Short-form video (TikTok, Reels, YouTube Shorts) सबसे ज़्यादा असर वाला मुफ़्त चैनल है, क्योंकि algorithm clips को उन लोगों तक पहुँचाता है जो आपको फ़ॉलो नहीं करते, X के उलट जहाँ organic पहुँच सिकुड़ गई है। एक clip किसी tweet से कहीं बेहतर कर सकती है। एक बात ईमानदारी से मान लें: 2025-2026 में organic short-video पहुँच मुश्किल हो गई है, इसलिए लगातार पोस्ट करने की उम्मीद रखें और YouTube Shorts को एक टिकाऊ विकल्प मानें जो click-through में भी अच्छा है।
• Devlogs, trailers, GIFs, capsule art: बार-बार सामने आना वह पहचान बनाता है जो wishlists में बदलती है, और लगातार clips एक मुफ़्त टेस्टिंग का भी काम करती हैं कि कौन-सा hook जमता है।
• Reddit: सही subs पर पोस्ट करें (r/IndieGaming, r/IndieDev, r/indiegames, r/playmygame, और साथ में niche वाले), और करीब 10-में-1 वाले नियम का पालन करें, आपकी सिर्फ़ करीब दस में से एक पोस्ट को सीधे आपके गेम को प्रमोट करना चाहिए। स्पैमी self-promo आपको ban करवा देती है।
• Discord: एक server दिलचस्पी रखने वाले प्लेयर्स को जोड़े रखता है, आपको playtesters देता है, और वह core बनाता है जो लॉन्च पर हाज़िर होता है।

बिना बजट के प्रेस और streamers

Streamers और YouTubers अब पारंपरिक प्रेस के मुकाबले इंडी discovery को ज़्यादा भरोसे के साथ चलाते हैं, और सही में से दो-चार creators आपकी सारी प्रेस आउटरीच से मिलकर भी ज़्यादा असर कर सकते हैं। वे मुफ़्त डेमो की सक्रिय तलाश में रहते हैं। पहुँच से ज़्यादा targeting मायने रखती है: ऐसे creators चुनें जिनकी audience आपके genre से मेल खाती हो और उन्हें बताएँ कि आपने उन्हें क्यों चुना।

प्रेस के लिए, pitches छोटी रखें (ज़्यादातर पत्रकार 200 शब्दों से कम पसंद करते हैं), उसमें एक hook, genre, press-kit लिंक, trailer, और एक key शामिल करें, और उसे पर्सनलाइज़ करें। एक one-page press kit लगाएँ जिसमें factsheet, high-res screenshots, एक trailer, और logos हों, आप जितनी रुकावट हटाते हैं उतनी आपकी संभावनाएँ बढ़ती हैं। लॉन्च से करीब दो हफ़्ते पहले review copies भेजें और streamers को करीब एक हफ़्ता पहले keys दें। आउटरीच की सबसे बड़ी गलती यह है कि किसी के दिलचस्पी दिखाने के बाद चुप हो जाना और मौका चूक जाना।

हकीकत भरी उम्मीदें

बुनियादी तस्वीर सोचने पर मजबूर करती है: 2024 में रिलीज़ हुए median Steam गेम ने बस कुछ सौ डॉलर कमाए, और रेवेन्यू में जीतने वाला सब कुछ ले जाता है। लेकिन यह discovery की समस्या है, माँग की नहीं, इंडीज़ अब Steam के रेवेन्यू और बिकी कॉपियों के करीब आधे हिस्से हैं। audience बहुत बड़ी है; आपका काम है ढूँढे जाने लायक होना। सबसे बड़ी गलती है चुपचाप बनाते रहना और आख़िरी हफ़्ते में मार्केटिंग शुरू करना। पूरी चुप्पी एक अधूरे गेम को दिखाने से ज़्यादा ख़तरनाक है।

एक बिना-बजट टाइमलाइन

• 6-12 महीने पहले: Steam "Coming Soon" पेज लगाएँ, clips और devlogs पोस्ट करना शुरू करें, एक Discord बनाना शुरू करें।
• 3-6 महीने पहले: लगातार short-form video, wishlists जमा करें, Next Fest की तैयारी करें।
• 4-6 हफ़्ते पहले: प्रेस और creator आउटरीच, trailer और press kit को अंतिम रूप दें।
• लॉन्च हफ़्ता: Reddit, सोशल, और प्रेस को उसी सुबह तालमेल में लाएँ; streamers को एक हफ़्ता पहले keys दें।

आम सवाल

बिना पैसे के मैं किसी इंडी गेम की मार्केटिंग कैसे करूँ?

जल्दी शुरू करें और मुफ़्त चैनलों पर टिकें: wishlists जमा करने के लिए महीनों पहले एक Steam पेज लगाएँ, अपने hook की short-form video clips पोस्ट करें, devlogs लिखें, सही Reddit और Discord communities में शेयर करें, और streamers और छोटी प्रेस को pitch करें। असली बात है समय के साथ लगातार बने रहना और एक साफ़, तेज़ hook, मार्केटिंग बजट नहीं।

Steam पर लॉन्च करने से पहले मुझे कितने wishlists चाहिए?

कोई जादुई नंबर नहीं है, लेकिन एक मोटा फ़्लोर करीब 7,000 है, जहाँ 7,000-10,000 आपको Popular Upcoming टैब पर मौका देते हैं। ज़्यादा बेहतर है, क्योंकि wishlists नोटिफिकेशन के ज़रिए लॉन्च-दिन की बिक्री में बदलते हैं। गहरी बात यह है कि उस हफ़्ते की टॉप रिलीज़ में से एक बनना, जो ज़्यादातर अपना पेज और मार्केटिंग जल्दी शुरू करने से आता है।

2026 में इंडी गेम्स के लिए सबसे अच्छा मुफ़्त मार्केटिंग चैनल कौन-सा है?

असली gameplay की short-form video (TikTok, Reels, YouTube Shorts), क्योंकि algorithms clips को non-followers तक पहुँचाते हैं, जिससे बिना मौजूदा audience के भी पहुँच मिलती है। Streamers और YouTubers भी बेहद असरदार हैं। organic short-video पहुँच कुछ साल पहले के मुकाबले मुश्किल हो गई है, इसलिए एक वायरल हिट की उम्मीद रखने के बजाय लगातार पोस्ट करें।

इंडी मार्केटिंग की सबसे बड़ी गलती क्या है?

चुपचाप बनाते रहना और आख़िरी हफ़्ते में मार्केटिंग शुरू करना। wishlists और एक audience जमा करने में मार्केटिंग को महीनों का lead time लगता है, इसलिए एक बढ़िया गेम भी अगर ठंडे तरीके से शून्य wishlists के साथ, बिना trailer और कमज़ोर स्टोर पेज के लॉन्च हो, तो दब जाता है। अपना गेम जल्दी दिखाएँ, भले ही अधूरा हो, और लॉन्च से बहुत पहले दिलचस्पी जमा करना शुरू करें।

संबंधित

• Steam Next Fest रणनीति — गहराई से demo-and-wishlist इवेंट
• इंडी गेम्स के लिए Kickstarter — अगर आप crowdfunding का रास्ता चुनते हैं
• itch.io पर अपना गेम कैसे लॉन्च करें — itch पर लॉन्च करना
• itch.io पर ज़्यादा प्लेज़ कैसे पाएँ — web-game ट्रैफ़िक चलाना
• 2026 में web game पब्लिश करने की सबसे अच्छी जगहें — web game कहाँ लगाएँ

आख़िरी बार अपडेट किया गया: जून 2026.

आपने एक वेब गेम बना लिया। अब क्या? आप इसे कहाँ पब्लिश करते हैं, यह तय करता है कि कितने लोग इसे खेलेंगे, आप कुछ कमाएँगे या नहीं, और आपके पास कितना कंट्रोल रहेगा। ये platforms इंस्टेंट-और-फ्री सेल्फ-पब्लिशिंग से लेकर करोड़ों प्लेयर वाले curated portals तक फैले हैं, जिनका बार ज़्यादा ऊँचा है। यहाँ 2026 का पूरा जायज़ा है, उन trade-offs के साथ जो सच में मायने रखते हैं।

तुलना

बड़े दो portals के बारे में एक बात: Poki और CrazyGames के पास सबसे बड़ी audiences हैं लेकिन सबसे ऊँचे बार और अनिवार्य SDKs भी। itch.io में सबसे ज़्यादा आज़ादी और सबसे अच्छा revenue split है, पर traffic आपको खुद लाना होगा। Kongregate को छोड़ दें, इसने 2020 में नए गेम लेना बंद कर दिया था और अब यह बस एक archive है।

पहले सेल्फ-पब्लिश करें: itch.io

ज़्यादातर indies के लिए itch.io डिफ़ॉल्ट शुरुआती जगह है। आप एक HTML5 build अपलोड करते हैं (एक ZIP जिसमें index.html हो), यह एक iframe में embed हो जाता है, और आप बिना किसी approval गेट के मिनटों में live हो जाते हैं। आप revenue split तय करते हैं (डिफ़ॉल्ट में आपको 90% मिलता है), और आप चार्ज कर सकते हैं, donations ले सकते हैं, या फ्री रख सकते हैं। दिक़्क़त यह है कि itch खुद अपने दम पर ज़्यादा टिकाऊ traffic नहीं लाता; प्लेयर आपको खुद यहाँ लाने पड़ते हैं। यह हमारी itch.io पर ज़्यादा प्लेज़ कैसे पाएँ गाइड में कवर किया गया है, और बुनियादी बातें itch.io लॉन्च गाइड में।

बड़े portals: CrazyGames और Poki

अगर आप करोड़ों की बिल्ट-इन audience चाहते हैं, तो casual portals वहीं हैं, लेकिन ये चुनिंदा हैं।

• CrazyGames (~35M monthly users) HTML5/WebGL गेम लेता है। एक बेसिक listing के लिए कम ज़रूरत होती है, पर monetization के साथ पूरा लॉन्च करने के लिए इसका SDK और QA पास करना ज़रूरी है, जिसमें ad blockers के साथ काम करना और सीधे gameplay में लैंड करना शामिल है। Payouts €100 से शुरू होते हैं।
• Poki (~100M monthly users) सबसे कड़ा है: एक कई-चरणों वाली pipeline जिसमें playtesting होती है, गेम को क्वालिटी, player fit और तकनीकी मज़बूती पर परखा जाता है। इसका SDK अनिवार्य है, और revenue deal इस पर निर्भर करता है कि प्लेयर कौन लाता है (जब आप लाएँ तो 100%, जब Poki लाए तो 50%)।

ये पॉलिश्ड, बहुत ऑप्टिमाइज़्ड casual गेम के लिए ठीक बैठते हैं, और इनकी प्रक्रिया से गुज़रना असल में काफ़ी मेहनत का काम है।

कम्युनिटी platforms: Newgrounds, GameJolt, gd.games

• Newgrounds कम्युनिटी-फ़र्स्ट है, जिसमें portal-voting सिस्टम और ad revenue sharing है। फ्री browser गेम और art/animation क्राउड के लिए बढ़िया।
• GameJolt अपना marketplace कट अधिकतम 10% रखता है और following व fanbase बनाने के इर्द-गिर्द बना है।
• gd.games GDevelop यूज़र्स को session-आधारित ad कमाई और editor से one-click publishing के साथ फ्री hosting देता है।

Distribution networks: GameDistribution, GameMonetize

ये एक HTML5 अपलोड को कई partner sites पर पैसिव reach के लिए syndicate करते हैं, बदले में बड़ा कट और अनिवार्य SDK लेते हैं। GameDistribution बड़ा हिस्सा लेता है; GameMonetize ज़्यादा split और तेज़, कम-थ्रेशोल्ड payouts देता है। Casual, puzzle और .io गेम के लिए अच्छा जहाँ split से ज़्यादा वॉल्यूम मायने रखता है।

सेल्फ-hosting को मत भूलें

एक HTML5 गेम बस static files होता है, इसलिए आप इसे GitHub Pages, Cloudflare Pages, Netlify या Vercel पर, अपने खुद के domain पर, फ्री होस्ट कर सकते हैं, कोई revenue कट नहीं देते और SEO व analytics पर पूरा कंट्रोल रखते हैं। नुक़सान यह है कि कोई बिल्ट-इन audience नहीं मिलती। एक आम तरीक़ा: अपने खुद के brand और SEO के लिए canonical वर्ज़न सेल्फ-होस्ट करें, और reach के लिए itch.io और एक-दो portal पर भी पब्लिश करें। अगर आपका गेम Cinevva जैसे किसी creator में बना है, तो आप इसे link से तुरंत शेयर भी कर सकते हैं और showcase में सबमिट कर सकते हैं।

कैसे चुनें

Platform को अपने लक्ष्य से मिलाएँ। सबसे ज़्यादा आज़ादी और सबसे अच्छा split चाहिए? itch.io और सेल्फ-hosting। सबसे बड़ी audience चाहिए और आपके पास एक पॉलिश्ड casual गेम है? Poki या CrazyGames। एक तैयार क्वालिटी गेम के लिए अपफ्रंट पेमेंट चाहिए? Armor Games को pitch करें। पैसिव syndicated reach चाहिए? कोई distribution network। ज़्यादातर indies एक साथ कई जगह पब्लिश करते हैं: home base के तौर पर itch.io, reach के लिए एक portal, और कंट्रोल के लिए अपना खुद का link।

आम सवाल

मुझे अपना HTML5 गेम कहाँ पब्लिश करना चाहिए?

itch.io से शुरू करें: यह इंस्टेंट है, फ्री है, आपको सबसे अच्छा revenue split देता है, और चार्ज करने या फ्री रखने की छूट देता है। बड़ी audience के लिए, पॉलिश्ड casual गेम CrazyGames या Poki को सबमिट करें (दोनों में चुनिंदा reviews और अनिवार्य SDKs हैं)। ज़्यादातर डेवलपर्स कई जगह पब्लिश करते हैं: itch.io के साथ एक portal और अपना खुद का सेल्फ-होस्टेड link।

कौन सा वेब गेम platform सबसे ज़्यादा पैसे देता है?

यह traffic और model पर निर्भर करता है। itch.io सबसे अच्छा split देता है (डिफ़ॉल्ट में आप 90%+ रखते हैं) पर audience आप लाते हैं। Poki और CrazyGames के पास बड़ी बिल्ट-इन audiences हैं लेकिन वे अपनी शर्तों पर ad revenue बाँटते हैं। Armor Games क्वालिटी गेम के लिए अपफ्रंट sponsorship फ़ीस देता है। कोई एक सबसे अच्छा नहीं है; कम traffic के साथ ऊँचा split, करोड़ों प्लेयर वाले छोटे split से कम कमा सकता है।

क्या वेब गेम पब्लिश करने के लिए मुझे SDK चाहिए?

itch.io, Newgrounds और GameJolt पर नहीं, आप बस अपलोड करते हैं। बड़े portals (Poki, CrazyGames) और distribution networks (GameDistribution, GameMonetize) पर monetization और पूरे लॉन्च के लिए SDK ज़रूरी है। SDK ads और platform फ़ीचर्स संभालता है। कहाँ पब्लिश करना है यह चुनते समय उस integration के काम को भी ध्यान में रखें।

क्या मैं वही वेब गेम कई platforms पर पब्लिश कर सकता हूँ?

आमतौर पर हाँ, जब तक आप किसी exclusive deal पर सहमत न हों (मिसाल के तौर पर, Poki का ज़्यादा revenue share web exclusivity माँग सकता है)। सेल्फ-hosting के साथ itch.io और एक non-exclusive portal एक आम मेल है। हर platform की शर्तें पढ़ें, क्योंकि exclusivity और revenue share अक्सर आपस में जुड़े होते हैं।

संबंधित

• itch.io पर अपना गेम कैसे लॉन्च करें — कदम-दर-कदम
• itch.io पर ज़्यादा प्लेज़ कैसे पाएँ — live होने के बाद traffic लाना
• बिना बजट के indie गेम कैसे प्रोमोट करें — $0 पर मार्केटिंग
• Steam Next Fest रणनीति — अगर आप Steam पर भी जाते हैं
• 2026 के लिए सबसे अच्छे वेब गेम engines — पहले गेम बनाना

आखिरी बार अपडेट किया गया: जून 2026.

जब आप free 3D assets ढूँढते हैं तो तीन नाम बार-बार सामने आते हैं: Sketchfab, Poly Haven, और Kenney। ये असल में एक-दूसरे के प्रतिद्वंद्वी नहीं हैं, ये अलग-अलग चीज़ों में अच्छे हैं। एक बहुत बड़ा mixed-license marketplace है, एक photorealistic और CC0 है, एक stylized और game-ready है। 2026 में ये कैसे तुलना में खड़े होते हैं और किसके लिए किसे चुनना है, यह रहा।

एक नज़र में

Kenney: एकसार और game-ready

एक जैसे दिखने वाले game तक पहुँचने का सबसे तेज़ रास्ता Kenney है। दसियों हज़ार assets, सभी CC0 (कोई attribution नहीं, commercial ठीक है), एक जैसे styles में जिन्हें आप packs के आर-पार मिला सकते हैं, सभी games के लिए optimized। इसका trade-off range है: यह photorealistic के बजाय stylized और साफ है, और आपको कोई एक खास हाइपर-डिटेल्ड prop यहाँ नहीं मिलेगा। Kenney तब इस्तेमाल करें जब आप चाहते हैं कि आपका पूरा game एक साथ का लगे, तेज़ी से, और licensing की बिल्कुल भी चिंता न हो।

Poly Haven: photorealistic और CC0

Poly Haven realism का विशेषज्ञ है: PBR-textured 3D models, high-resolution textures, और lighting के लिए HDRIs, सभी CC0, कई resolutions और direct downloads के लिए एक no-key API के साथ। 2,000 से ज़्यादा assets और लगातार बढ़ रहे हैं। Catalog छोटा और ज़्यादा केंद्रित है (props, environment के टुकड़े, materials, lighting) न कि कोई फैला हुआ marketplace। Poly Haven तब इस्तेमाल करें जब आप बिना किसी attribution के realistic materials, environment dressing, और सही HDRI lighting चाहते हैं।

Sketchfab: variety, license जाँचने की शर्त के साथ

Sketchfab दानव है: करोड़ों models, download से पहले एक 3D preview, और styles व विषयों की बहुत बड़ी range। पेच यह है कि licenses हर model के हिसाब से अलग होते हैं, इसलिए आपको downloadable के साथ CC0 या CC-BY के लिए filter करना होगा और हर एक को verify करना होगा। एक 2026 की चेतावनी: Sketchfab का store Epic के Fab में चला गया, और सिर्फ़ CC-BY और Fab Standard content ही migrate हो सकता है। CC0 और दूसरे Creative Commons models फ़िलहाल Sketchfab पर downloadable रहते हैं, लेकिन इसे धीरे-धीरे घटता हुआ CC0 source मानें और जो चाहिए वह ले लें। Sketchfab तब इस्तेमाल करें जब आपको कोई खास या असामान्य model चाहिए जो बाकी दोनों के पास नहीं है, और आप license जाँचने के लिए तैयार हैं।

आपको किसे इस्तेमाल करना चाहिए?

• पूरे-game की एकरूपता, तेज़, कोई attribution नहीं: Kenney।
• Realistic props, materials, और lighting, CC0: Poly Haven।
• कोई खास या असामान्य model, सबसे बड़ा चयन: Sketchfab (license जाँचें)।

व्यवहार में, कई developers तीनों इस्तेमाल करते हैं: base set और UI के लिए Kenney, realistic textures और HDRIs के लिए Poly Haven, और एक-अकेले hero asset के लिए Sketchfab। realistic Poly Haven materials को stylized Kenney models पर मिलाना टकरा सकता है, इसलिए पहले अपनी art direction तय करें, फिर उससे मेल खाते sources चुनें।

तीन बड़े नामों से आगे

ये आपके इकलौते विकल्प नहीं हैं। Quaternius stylized low-poly के लिए एक और बेहतरीन CC0 source है, AmbientCG CC0 textures में माहिर है, और Poly Pizza archived Google Poly catalog को होस्ट करता है। आप AI से भी models बना सकते हैं। पूरे नज़ारे के लिए, हमारी free 3D model sites और free game assets guides देखें।

आम सवाल

Free 3D models के लिए Sketchfab, Poly Haven, या Kenney में से सबसे अच्छा कौन है?

ये अलग-अलग चीज़ों में सबसे अच्छे हैं। Kenney एकसार, game-ready stylized assets के लिए सबसे अच्छा है, सभी CC0। Poly Haven photorealistic models, textures, और HDRIs के लिए सबसे अच्छा है, सभी CC0। Sketchfab variety और खास या विस्तृत models के लिए सबसे अच्छा है, लेकिन इसके licenses अलग-अलग होते हैं इसलिए आपको हर एक जाँचना होगा। कई developers तीनों को साथ में इस्तेमाल करते हैं।

क्या Poly Haven और Kenney सचमुच commercial games के लिए free हैं?

हाँ। दोनों पूरी तरह CC0 हैं, यानी हर asset public domain है: commercial इस्तेमाल के लिए free, बदला जा सकने वाला, और कोई attribution ज़रूरी नहीं। इससे ये तीनों में सबसे कम जोखिम वाले दो sources बन जाते हैं। इसके उलट Sketchfab के हर-model पर अलग licenses होते हैं जिन्हें commercial इस्तेमाल से पहले आपको verify करना होगा।

क्या मुझे इन sites के assets को credit देना पड़ेगा?

Kenney या Poly Haven के लिए नहीं, क्योंकि सब कुछ CC0 है। Sketchfab के लिए यह हर model के license पर निर्भर करता है: CC0 को किसी credit की ज़रूरत नहीं, CC-BY के लिए attribution ज़रूरी है, और कुछ models को commercial तौर पर बिल्कुल भी इस्तेमाल नहीं किया जा सकता। ship करने से पहले हमेशा हर Sketchfab model का license जाँचें।

क्या मैं एक ही game में तीनों के assets मिला सकता हूँ?

तकनीकी तौर पर हाँ, और licenses इसकी इजाज़त देते हैं, लेकिन अपनी art direction का ध्यान रखें। Kenney का stylized लुक और Poly Haven के photorealistic materials अगर लापरवाही से मिलाए जाएँ तो टकरा सकते हैं। पहले एक visual style तय करें, फिर मेल खाते assets लें, और जो पीस CC0 sources के पास नहीं हैं उनके लिए Sketchfab का इस्तेमाल करें।

संबंधित

• Games के लिए सबसे अच्छी Free 3D Model Sites — बड़ा मैदान
• Free Game Assets कहाँ मिलें — 20+ sources, सभी तरह के
• Games के लिए सबसे अच्छे AI Asset Generators — इसके बजाय बनाएँ
• Game Asset Licenses समझाए गए — CC0, CC-BY, और बाकी
• Games के लिए Free Sound Effects और Music — audio वाला पहलू

आख़िरी बार अपडेट किया गया: जून 2026.

अगर आपको एक ऐसा 3D game चाहिए जो browser में चले, तो तीन engine सबसे ज़्यादा सामने आते हैं: Unity, Godot, और PlayCanvas। ये web तक बहुत अलग-अलग रास्तों से पहुँचते हैं। Unity एक desktop पावरहाउस है जो WebGL पर export करता है, Godot एक फ़्री ओपन-सोर्स ऑल-राउंडर है, और PlayCanvas शुरू से ही web के लिए बनाया गया है। खास browser 3D के लिए 2026 में इनकी तुलना ऐसी दिखती है।

झटपट फ़ैसला

• Web-first 3D, सबसे छोटे builds, सबसे बेहतर WebGPU: PlayCanvas।
• फ़्री, ओपन-सोर्स, 2D और 3D दोनों, web और native के लिए एक ही codebase: Godot।
• आपके पास पहले से एक Unity project है, या आपको console और हाई-एंड native भी चाहिए: Unity, बड़ा web download मानते हुए।

तुलना

Unity (WebGL)

Unity खेलने लायक WebGL builds export करता है, और इसका ecosystem (Asset Store, tooling, docs) बेजोड़ है। खास web के लिए पेच यह है: खाली builds करीब 8 MB से शुरू होते हैं, load time web-native engines से पीछे रहता है, और mobile browser की memory तंग पड़ सकती है। WebGPU मौजूद है पर experimental है और डिफ़ॉल्ट रूप से बंद है; असली target WebGL2 है। एक प्रैक्टिकल दिक्कत यह है कि browser में डालने के लिए Unity सबसे भारी विकल्प है, इसलिए यह तब चमकता है जब web किसी ऐसे game के लिए एक सेकंडरी target हो जो desktop, mobile, या console पर भी जाता है। Unity ने अपने Muse AI tool की जगह Unity AI (ओपन बीटा, 2026) भी ला दिया है, अगर आपको editor के अंदर AI मदद चाहिए।

Godot (4.7)

Godot, MIT license के तहत फ़्री और ओपन-सोर्स है, इसमें कोई revenue कैप या seat फ़ीस नहीं है, और यह 2D और 3D दोनों को अच्छी तरह संभालता है। वर्ज़न 4.7 (जून 2026) डिफ़ॉल्ट रूप से WebAssembly SIMD के साथ आता है और इसमें wasm64 export विकल्प जोड़ा गया है, जो पुरानी 4 GB memory सीमा हटा देता है। Web rendering अब भी सिर्फ़ WebGL 2.0 (Compatibility renderer) है, क्योंकि Godot में अभी WebGPU support नहीं है। दो web पेच अब भी बाक़ी हैं: C# projects web पर export नहीं हो सकते (सिर्फ़ GDScript), और SharedArrayBuffer threading के लिए ख़ास COOP/COEP server headers चाहिए, जो कुछ hosts पर अटका सकते हैं। ऐसे indie के लिए जो licensing की चिंता के बिना web और native दोनों के लिए एक ही engine चाहता है, Godot मज़बूत फ़्री पसंद है।

PlayCanvas

PlayCanvas पहले दिन से web के लिए डिज़ाइन किया गया था। इसका runtime बहुत छोटा (~1-2 MB) है, यह तीनों में सबसे तेज़ लोड होता है, और किसी भी web engine के मुकाबले इसका WebGPU renderer सबसे प्रोडक्शन-रेडी है, जिसमें v2.20 (जून 2026) से compute-आधारित 3D Gaussian splat rendering भी शामिल है। editor cloud-आधारित और collaborative है, जो teams के लिए ठीक है पर हर किसी के workflow में फ़िट नहीं बैठेगा। यह 3D-first है और जटिल 2D के लिए कम मुफ़ीद है। अगर download size और web performance आपकी प्राथमिकताएँ हैं, तो PlayCanvas ठीक इसी के लिए बना है।

कैसे चुनें

अपनी असल पाबंदी के हिसाब से चुनें। अगर आपको सबसे छोटा, सबसे तेज़ लोड होने वाला 3D web build और अच्छा WebGPU चाहिए, तो PlayCanvas चुनें। अगर आप एक फ़्री, ओपन engine चाहते हैं जो 2D और 3D दोनों करे और एक ही codebase से desktop और mobile पर भी export करे, तो Godot चुनें। अगर आपका game पहले से Unity में रहता है या उसे सचमुच Unity की हाई-एंड rendering और console export की ज़रूरत है, तो WebGL build निकालें और बड़ा download मान लें।

अगर आप engine को पूरी तरह छोड़कर एक AI को एक 3D web game बताना चाहें, तो वह एक अलग रास्ता है, जिसे बिना coding के 3D browser game कैसे बनाएँ में समझाया गया है।

आम सवाल

3D browser games के लिए सबसे बेहतर engine कौन सा है?

2026 में PlayCanvas सबसे मज़बूत web-first पसंद है: छोटा runtime, सबसे तेज़ load, और सबसे परिपक्व WebGPU renderer। Godot सबसे बेहतर फ़्री, ओपन-सोर्स विकल्प है और native पर भी export करता है। Unity तभी सबसे बेहतर है जब आपका game पहले से इसका इस्तेमाल करता हो या उसे इसके हाई-एंड फ़ीचर चाहिए हों, क्योंकि इसके web builds सबसे बड़े होते हैं। सबसे बेहतर चुनाव build size, इस बात पर कि आपको native export चाहिए या नहीं, और आपके बजट पर निर्भर करता है।

क्या Unity और Godot, C# games को web पर export कर सकते हैं?

यह एक आम पेच है: Godot, C# projects को web पर बिल्कुल export नहीं कर सकता (सिर्फ़ GDScript)। Unity का web export C# इस्तेमाल करता है, पर यह Wasm के ज़रिए WebGL पर कंपाइल होता है, और नतीजे में बनने वाले builds बड़े होते हैं (~8 MB+ खाली)। PlayCanvas नेटिव रूप से JavaScript या TypeScript इस्तेमाल करता है, जो एक वजह है कि इसके web builds इतने छोटे होते हैं।

browser में सबसे तेज़ कौन लोड होता है?

PlayCanvas, बड़े अंतर से, क्योंकि इसका ~1-2 MB runtime ख़ास web के लिए बना है। Godot के खाली builds करीब 9 MB gzipped होते हैं, और Unity के 8 MB से शुरू होकर ऊपर जाते हैं। web games के लिए, कुल download size इस बात पर काफ़ी असर डालता है कि कितने players असल में load होने का इंतज़ार करते हैं, इसलिए यह एक असल चुनाव-कारक है, कोई मामूली बात नहीं।

क्या ये engine WebGPU को सपोर्ट करते हैं?

PlayCanvas का WebGPU renderer सबसे परिपक्व है। Godot का web export अब भी सिर्फ़ WebGL2 है, WebGPU support अभी नहीं है। Unity, WebGPU को experimental रखता है और डिफ़ॉल्ट रूप से WebGL2 पर रहता है। इस ट्रेड-ऑफ़ को गहराई से देखने के लिए, हमारी WebGPU बनाम WebGL guide देखें।

संबंधित

• 2026 के लिए सबसे बेहतर Web Game Engines — 11 engines का पूरा मैदान
• Games के लिए WebGPU बनाम WebGL — rendering API का ट्रेड-ऑफ़
• PlayCanvas बनाम Three.js — web 3D के लिए engine बनाम library
• Web Games के लिए Godot बनाम Unity — दो बड़े full engines आमने-सामने

आखिरी बार अपडेट किया गया: जून 2026.

"Vibe coding" एक ट्वीट से Collins Dictionary का Word of the Year बनने में एक साल भी नहीं लगा। गेम्स के लिए यह अभी बनाने के सबसे मजेदार तरीकों में से एक है: आप बताते हैं कि आपको क्या चाहिए, AI उसे लिख देता है, और आप syntax के बजाय अपने अंदाज से गेम को दिशा देते हैं। यहां बताया गया है कि इस शब्द का असल मतलब क्या है, किसी गेम को vibe-code कैसे करें, और यह कहां काम करता है और कहां अड़चन बनता है।

यह शब्द कहां से आया

यह वाक्यांश OpenAI के एक सह-संस्थापक सदस्य Andrej Karpathy की फरवरी 2025 की एक पोस्ट से आया। उन्होंने इसे "एक नए तरह की coding बताया जहां आप पूरी तरह vibes के हवाले हो जाते हैं, exponentials को अपनाते हैं, और भूल जाते हैं कि code का कोई वजूद भी है," जो इसलिए मुमकिन है क्योंकि AI coding मॉडल इतने अच्छे हो गए हैं कि आप "बस चीजें देख सकते हैं, चीजें बोल सकते हैं, चीजें चला सकते हैं, और चीजें copy-paste कर सकते हैं, और ज्यादातर यह काम कर जाता है।" उन्होंने इसे वीकेंड में बनाए जाने वाले फेंकने-लायक प्रोजेक्ट्स के लिए बताया था, यह याद रखने लायक बात है।

डेवलपर Simon Willison ने परिभाषा को और साफ किया: असली vibe coding का मतलब है किसी LLM के साथ software बनाना बिना उसके लिखे code को पढ़े। अगर आप हर लाइन पढ़ते, test करते और समझते हैं, तो आप AI को एक typing assistant की तरह इस्तेमाल कर रहे हैं, जो एक अलग बात है। 2025 के आखिर तक यह शब्द इतना फैल चुका था कि Collins ने इसे Word of the Year घोषित कर दिया।

गेम्स के लिए यह साफ-साफ बैठता है: आप एक गेम बताते हैं, AI उसे बनाता है, आप उसे खेलते हैं और बदलाव मांगते हैं, और आप ज्यादातर code की तरफ देखते ही नहीं। यही किसी गेम को vibe-code करना है।

गेम्स इसके लिए इतने बढ़िया क्यों हैं

गेम्स visual होते हैं और तुरंत टेस्ट किए जा सकते हैं, और यही वह loop है जिसे vibe coding इनाम देता है। आप दो सेकंड में देख सकते हैं कि जंप सही लग रही है या दुश्मन बहुत तेज है, इसलिए "चीजें बोलो, चीजें चलाओ" वाला चक्र कसा हुआ और संतोषजनक रहता है। और मशहूर सबूत खुद एक गेम है: 2025 की शुरुआत में indie डेवलपर Pieter Levels ने बिना किसी game-dev पृष्ठभूमि के, एक AI code editor और Three.js का इस्तेमाल करके कुछ ही घंटों में एक browser 3D फ्लाइट सिम्युलेटर vibe-code कर दिया, और यह वायरल हिट बन गया। (उनके revenue के आंकड़े खुद उनके बताए हुए हैं, इसलिए डॉलर की रकम को थोड़ा शक के साथ लें, लेकिन खुद बनाया गया गेम असली है और अच्छे से दर्ज है।)

किसी गेम को vibe-code करने के दो तरीके

दो अंदाज हैं, इस पर निर्भर करते हुए कि आप कितना खुद छूना चाहते हैं।

सामान्य AI coding tools। Cursor, Claude Code और GitHub Copilot आपको उसी तरह गेम बनाने देते हैं जैसा Karpathy ने बताया था: किसी AI coding agent को prompt दें, आमतौर पर Three.js जैसे किसी web framework के साथ, और सुधार करते जाएं। आपको code पढ़ना जरूरी नहीं, लेकिन प्रोजेक्ट एक असली codebase होता है जिसे आप कहीं भी ले जा सकते हैं। यह सबसे लचीला रास्ता है और सबसे ताकतवर भी, जिसमें खुद को फंसाने की सबसे ज्यादा गुंजाइश भी है।

गेम-खास prompt-to-game tools। Cinevva, Rosebud, Summer, Replit और Nilo पूरे loop को एक खास मकसद से बने माहौल में लपेट देते हैं। आप एक गेम बताते हैं, यह एक खेलने लायक गेम बनाता है, और आप chat करके उसे संवारते हैं, जिसमें assets आपके लिए जनरेट होते हैं। यह सबसे आसान शुरुआत है और शेयर करने लायक नतीजे तक सबसे तेज। हमारी AI गेम जनरेटर तुलना बताती है कि कौन सा कौन है।

किसी गेम को vibe-code कैसे करें, कदम दर कदम

1. एक छोटा आइडिया चुनें। vibe coding वीकेंड-भर के दायरे पर चमकती है। एक genre, एक ट्विस्ट, और एक लक्ष्य तय करें।
2. एक-वाक्य का prompt लिखें। "एक neon snake गेम बनाओ जो बढ़ने के साथ तेज होता जाए।" tool को पहला वर्जन बनाने दें। खाली पन्ने से बचने के लिए आप एक-क्लिक prompt आजमा सकते हैं।
3. खेलें, फिर एक बदलाव मांगें। "इसे तेज करो," "एक score जोड़ो," "controls चिपचिपे लगते हैं, उन्हें चुस्त बनाओ।" बदलो, खेलो, दोहराओ।
4. मांग कर assets जनरेट करें। "इसे low-poly लुक दो," "उत्साहित करने वाला music जोड़ो," "एक रेगिस्तान वाला skybox इस्तेमाल करो।"
5. link पब्लिश करें। Browser tools एक क्लिक में शेयर कर देते हैं। इसे लोगों के सामने रखें और उनकी प्रतिक्रियाओं को अगले दौर की दिशा तय करने दें।

अगर आप करके सीखना चाहते हैं तो आप अभी अपने browser में मुफ्त में एक 3D गेम vibe-code करना शुरू कर सकते हैं।

गलतियां (और उनसे कैसे बचें)

vibe coding ताकतवर है, लेकिन 2026 की ईमानदार तस्वीर में असली चेतावनी के संकेत हैं:

• "लगभग सही, पर पूरा नहीं।" दो-तिहाई डेवलपर इसे अपनी सबसे बड़ी AI परेशानी बताते हैं। गेम्स के लिए इसका हल है छोटे, खास अनुरोध और यह तैयारी कि जब कोई बदलाव चीजों को बिगाड़ दे तो उसे वापस पलट दें।
• Security और quality का कर्ज। 2025 के अध्ययनों में पाया गया कि AI-जनरेटेड code के नमूनों का एक बड़ा हिस्सा security खामियां लाता है, और यह कि दोहराया हुआ, बिना refactor किया गया code बढ़ रहा है। किसी फेंकने-लायक गेम के लिए इससे शायद ही फर्क पड़ता हो; पर किसी ऐसी चीज के लिए जो user डेटा या पैसे संभालती है, code की समीक्षा करें या किसी ऐसे इंसान से करवाएं जो कर सके।
• यह तब तक चलता है जब तक नहीं चलता। एक व्यापक रूप से रिपोर्ट किए गए मामले में, एक AI coding agent ने code freeze के दौरान एक production database मिटा दिया। सबक: बैकअप रखें, प्रयोगों को किसी भी जरूरी चीज से अलग रखें, और किसी vibe-coding agent को ऐसे systems की तरफ मत लगाएं जिन्हें आप खोने का जोखिम नहीं उठा सकते।

Karpathy ने खुद बाद में उस मूल पोस्ट को "एक फेंकने-लायक ट्वीट" कहा और गंभीर काम के लिए ज्यादा सावधान भाषा पसंद करते हैं। नतीजा यह नहीं है कि vibe coding बुरी है, बल्कि यह है कि यह प्रोटोटाइप और छोटे गेम्स के लिए शानदार है और उन चीजों के लिए आपके इकलौते तरीके के रूप में जोखिम भरी है जिन्हें सही होना जरूरी है।

क्या vibe coding "असली" गेम डेवलपमेंट है?

यह बनाने का एक असली और काम का तरीका है, खासकर प्रोटोटाइप, jams और छोटे गेम्स के लिए, और बहुत सारे लोग पहली बार गेम्स में इसी तरह आ रहे हैं। जब दांव ऊंचे हों तो यह इस बात की जगह नहीं ले सकता कि आप जो बना रहे हैं उसे समझें। 2026 में सबसे उत्पादक रुख यह है कि जल्दी खोजने और प्रोटोटाइप बनाने के लिए vibe-code करें, फिर रुककर उन हिस्सों को समझें जिन्हें भरोसेमंद होना जरूरी है। ज्यादातर browser गेम्स के लिए वह रेखा आराम से आपके फायदे में बैठती है।

आम सवाल

vibe coding का मतलब क्या है?

vibe coding का मतलब है किसी AI को बताकर कि आपको क्या चाहिए software बनाना और उसे code लिखने देना, बिना खुद code की समीक्षा किए। यह शब्द Andrej Karpathy ने फरवरी 2025 में गढ़ा और 2025 में इसे Collins Word of the Year चुना गया। गेम्स के लिए इसका मतलब है किसी गेम को सादी भाषा में बताना और code लिखने के बजाय chat करके उसे संवारना।

मैं किसी गेम को vibe-code करना कैसे शुरू करूं?

एक छोटा आइडिया चुनें, उसे एक वाक्य में किसी prompt-to-game tool या किसी AI code editor को बताएं, पहला वर्जन खेलें, और एक बार में एक बदलाव मांगें। Browser पर चलने वाले AI गेम creators शुरुआत के लिए सबसे आसान हैं क्योंकि वे एक खेलने लायक गेम बना देते हैं और बिना किसी setup के उसे तुरंत शेयर करने देते हैं।

क्या गेम बनाने के लिए vibe coding अच्छी है?

हां, खासकर प्रोटोटाइप और छोटे या casual गेम्स के लिए, जहां तेज बताओ-खेलो-संवारो loop बढ़िया बैठता है। यह बड़े, जटिल, या सही-होना-जरूरी प्रोजेक्ट्स के लिए कमजोर है, जहां बिना समीक्षा वाला AI code बग और security दिक्कतें ला सकता है। तेज चलने के लिए इसका इस्तेमाल करें, और किसी भी ऐसी चीज के लिए code की समीक्षा करें जिसे भरोसेमंद होना जरूरी है।

लोग गेम्स को vibe-code करने के लिए कौन से tools इस्तेमाल करते हैं?

दो तरह के। Cursor, Claude Code और GitHub Copilot जैसे सामान्य AI coding tools (अक्सर web के लिए Three.js के साथ), और Cinevva, Rosebud, Summer, Replit और Nilo जैसे गेम-खास prompt-to-game tools। गेम-खास tools आसान शुरुआत हैं; coding tools ज्यादा लचीले हैं।

संबंधित

• 2026 में सबसे अच्छे AI गेम जनरेटर — tools की तुलना
• AI से गेम कैसे बनाएं (बिना coding) — कदम दर कदम workflow
• बिना coding के 3D Browser गेम कैसे बनाएं — 3D रास्ता
• एक क्लिक में बनाने लायक AI गेम Prompts — शुरू करने के लिए prompts
• 2026 के लिए सबसे अच्छे Web गेम Engines — पारंपरिक तरीके से बनाने के लिए

आखिरी बार अपडेट किया गया: जून 2026.

एक दशक से भी ज़्यादा समय तक, browser में असली graphics डालने का एकमात्र तरीका WebGL था। WebGPU इसका उत्तराधिकारी है, और 2026 वह साल है जब यह वाकई हर जगह इस्तेमाल के लायक बन गया। अगर आप एक web game बना रहे हैं और सोच रहे हैं कि किसे target करें, तो यहाँ ईमानदार तुलना है: क्या बदला, कहाँ कौन जीतता है, और आपका engine पहले से क्या इस्तेमाल करता है।

छोटा जवाब

WebGL एक graphics API है जो OpenGL ES पर आधारित है और drawing के लिए बना है। WebGPU एक आधुनिक API है जो Vulkan, Metal, और Direct3D 12 पर आधारित है, और drawing तथा सामान्य GPU compute दोनों के लिए बना है। WebGPU भारी scenes के लिए तेज़ है, compute shaders (particles, simulation, GPU पर culling) की सुविधा देता है, और इसका API ज़्यादा साफ-सुथरा है। WebGL पुराना, सरल है, और लगभग हर मौजूद device पर support करता है।

2026 में क्या बदला

मुख्य बात: WebGPU आखिरकार cross-browser हो गया। Safari 26 (सितंबर 2025) ने macOS, iPadOS, iOS, और visionOS पर WebGPU भेज दिया, जिससे आखिरी बड़ी बाधा भी हट गई। इससे पहले, "बस WebGL इस्तेमाल करो क्योंकि Safari और iOS WebGPU support नहीं करते" सही सलाह थी। अब ऐसा नहीं है। Chrome और Firefox के पास यह पहले से था, तो 2026 तक WebGPU सभी बड़े browsers पर चलता है।

इसका मतलब यह नहीं कि WebGPU हर जगह default है। ज़्यादातर engines में यह अब भी opt-in या experimental है (इस पर नीचे और बात), और WebGL2 अब भी सुरक्षित baseline बना हुआ है। पर browser-support की जो दीवार WebGPU को अपनाने से रोक रही थी, वह हट गई है।

आमने-सामने

WebGPU कब जीतता है

• बहुत सारे objects या draw calls। WebGPU का कम CPU overhead और multi-draw जैसे features का मतलब है कि यह वहाँ भी frame rate बनाए रखता है जहाँ WebGL draw-call count पर अटकने लगता है।
• GPU compute। Particle systems, physics, culling, procedural generation, और 3D Gaussian splatting compute shaders के ज़रिए GPU पर चल सकते हैं। WebGL यह बस कर ही नहीं सकता।
• भविष्य के लिए तैयारी। platform जिस दिशा में जा रहा है वह WebGPU है; नए engine features तेज़ी से पहले वहीं आने लगे हैं।

WebGL अब भी कब सही विकल्प है

• पुराने या low-end devices पर अधिकतम पहुँच। WebGL2 उस hardware और उन browser versions पर चलता है जिनमें अभी काम करने वाला WebGPU path न हो।
• सरल 2D और हल्का 3D। अगर आपका game GPU पर ज़ोर नहीं डाल रहा, तो WebGL काफी है और नए drivers के किसी भी edge case से बचाता है।
• आज आप सबसे सुरक्षित baseline चाहते हैं। बिना किसी fallback logic के WebGL2 भेजना एक बड़े audience के लिए अब भी सबसे कम जोखिम वाला विकल्प है।

ज़्यादातर games के लिए 2026 का व्यावहारिक जवाब: ऐसे engine पर बनाएँ जो दोनों को support करता हो और जहाँ उपलब्ध हो वहाँ WebGPU इस्तेमाल करे, साथ में एक automatic WebGL2 fallback के साथ। आपको जहाँ speed मौजूद है वहाँ speed मिलती है और जहाँ नहीं है वहाँ compatibility, और दो renderers लिखने की ज़रूरत नहीं पड़ती।

आपका engine पहले से क्या इस्तेमाल करता है

हमारी web game engines की तुलना से, 2026 में बड़े web engines WebGPU पर कहाँ खड़े हैं:

• PlayCanvas के पास web engines में सबसे production-ready WebGPU renderer है, जिसमें compute-आधारित Gaussian splat rendering शामिल है।
• Three.js एक zero-config WebGPU renderer (three/webgpu) भेजता है जिसमें automatic WebGL2 fallback है, हालाँकि default export अब भी WebGL है।
• Babylon.js WebGPU support करता है (WebGPUEngine में opt-in करें); version 8 ने WebGPU build size भी आधा कर दिया।
• Godot में अभी WebGPU support नहीं है। 4.7 में web export अब भी सिर्फ़ WebGL2 है, हालाँकि wasm64 builds अब पुरानी 4 GB memory सीमा हटा देते हैं।
• Cocos Creator के पास अपनी नई render pipeline के ज़रिए experimental WebGPU है।
• Unity WebGPU को experimental और WebGL2 को default web target बनाए रखता है।
• Phaser 4 एक WebGL2 rewrite है जिसमें अभी WebGPU नहीं है; PixiJS WebGPU support करता है पर default WebGL है।

तो व्यवहार में, WebGPU-या-WebGL का फैसला आमतौर पर engine ही आपके लिए कर देता है, और अच्छे engines अपने-आप fallback कर लेते हैं।

Browser support की झलक (2026)

अगर आप बड़े audience को target करते हैं तो हमेशा Safari/iOS पर test करें, और पुराने devices की long tail के लिए एक WebGL2 fallback रखें।

आम सवाल

क्या games के लिए WebGPU, WebGL से बेहतर है?

मांग वाले games के लिए, हाँ: WebGPU का CPU overhead कम है, यह ज़्यादा objects संभालता है, और ऐसे effects के लिए compute shaders जोड़ता है जो WebGL नहीं कर सकता। सरल 2D या हल्के 3D के लिए, WebGL2 अब भी काफी है और पुराने devices पर इसका support ज़्यादा व्यापक है। 2026 में सबसे अच्छा तरीका एक ऐसा engine है जो जहाँ उपलब्ध हो वहाँ WebGPU इस्तेमाल करे और अपने-आप WebGL2 पर fallback कर ले।

क्या 2026 में WebGPU, Safari और iOS पर काम करता है?

हाँ। सितंबर 2025 में जारी हुए Safari 26 ने macOS, iPadOS, iOS, और visionOS पर WebGPU जोड़ा। इससे आखिरी बड़ी कमी भी पूरी हो गई, तो अब WebGPU Chrome, Firefox, और Safari पर, mobile समेत काम करता है। पुराने devices और browser versions में अब भी यह न हो, इसलिए एक WebGL2 fallback रखें।

मुझे पहले WebGPU सीखना चाहिए या WebGL?

अगर आप एक game engine इस्तेमाल कर रहे हैं, तो आमतौर पर आप इनमें से कुछ भी सीधे नहीं लिखते, engine ही संभाल लेता है। अगर आप हाथ से graphics code लिख रहे हैं, तो WebGPU सीखने के लिए ज़्यादा भविष्य-सुरक्षित API है, पर आज WebGL के पास ज़्यादा tutorials और examples हैं। कई developers अब भी WebGL या Three.js जैसी library से शुरुआत करते हैं, जो अब तैयार होने पर एक WebGPU renderer भी देती है।

क्या WebGPU, WebGL की जगह ले लेगा?

आखिरकार, ज़्यादातर नया development WebGPU को target करेगा, पर WebGL जल्दी गायब नहीं होगा। यह पुराने hardware के लिए सार्वभौमिक baseline बना हुआ है और मौजूदा tools तथा content में गहराई से बसा हुआ है। लंबे समय तक ऐसा ओवरलैप रहेगा जहाँ engines दोनों को support करते हैं और runtime पर चुनते हैं।

संबंधित

• 2026 के लिए सबसे अच्छे Web Game Engines — पूरा मैदान, हर engine की WebGPU स्थिति के साथ
• 2026 में Web Games का Tech Stack — API स्तर पर WebGL, WebGPU, और Wasm
• Unity WebGL बनाम Godot बनाम PlayCanvas — तीन बड़े 3D web engines
• PlayCanvas बनाम Three.js — web 3D के लिए engine बनाम library

Vibe coding अभी गेम बनाने का सबसे तेज़ तरीका है। आप साधारण अंग्रेज़ी में बताते हैं कि आप क्या चाहते हैं और AI उसे बना देता है। न कोई engine install करना, न कोई code लिखना, न किसी asset store में खोजबीन करना।

नीचे 12 prompts हैं जो हमें पसंद हैं। किसी पर भी क्लिक करें और Cinevva उस idea के साथ खुलता है जो पहले से टाइप किया हुआ है, और एक खेलने लायक 3D गेम बनाना शुरू कर देता है जिसे आप edit कर सकते हैं। ये सभी आपके browser में चलते हैं और सभी आज़माने के लिए मुफ़्त हैं। इन्हें उठा लें, एक शब्द बदल दें, या अपना खुद का लिखें।

अपना खुद का कैसे लिखें

ऊपर दिए गए prompts जानबूझकर छोटे हैं। आपको हर नियम विस्तार से बताने की ज़रूरत नहीं है। गेम का प्रकार बताएँ, एक चीज़ जो इसे आपका बनाती है, और एक goal। बाकी AI भर देता है, और एक बार चलने पर आप उसे बताते हैं कि क्या बदलना है।

इसके बजाय एक खाली canvas चाहिए? creator खोलें और अपना खुद का idea टाइप करें।

ओपन-सोर्स गेम इंजन आपको कुछ ऐसा देते हैं जो proprietary इंजन नहीं दे सकते: एक ऐसा लाइसेंस जो आपके गेम को ship करने के बाद नहीं बदलेगा। न per-seat फीस, न revenue थ्रेशोल्ड, न अचानक आने वाली कीमतें। आप सोर्स पढ़ सकते हैं, उसे fork कर सकते हैं, और बनाते रह सकते हैं, भले ही मूल टीम काम छोड़ दे। Unity Runtime Fee की घटना के बाद, यही स्थिरता वह वजह थी जिसके चलते बहुत सी टीमें पहली बार ओपन सोर्स की ओर गईं।

यह 2026 में इस्तेमाल करने लायक ओपन-सोर्स गेम इंजन की पूरी सूची है, इस आधार पर समूहबद्ध कि वे किस काम के लिए हैं। अगर आपको खासतौर पर एक web build चाहिए, तो हमने बता दिया है कि कौन से इंजन browser में export करते हैं, और आप हमारी सबसे बेहतरीन web game इंजन की तुलना में और गहराई तक जा सकते हैं।

जल्दी तुलना

कोई एक "सबसे अच्छा" ओपन-सोर्स इंजन नहीं है। सही इंजन इस पर निर्भर करता है कि 2D है या 3D, आपकी भाषा क्या है, और आप web को target कर रहे हैं या नहीं।

पूरे 2D और 3D इंजन

Godot

जब लोग "ओपन-सोर्स गेम इंजन" कहते हैं तो ज़्यादातर का मतलब Godot ही होता है। यह MIT लाइसेंस वाला है, 2D और 3D दोनों करता है, और किसी भी तरह की फीस या revenue cap नहीं रखता। यह छोटे web builds (compressed करीब 5 MB) ship करता है, और 4.3 से single-threaded export कर सकता है, जिससे iOS और Safari पर साफ़ सपोर्ट मिलता है। एक web चेतावनी यह है कि C# प्रोजेक्ट अभी browser में export नहीं हो सकते, सिर्फ़ GDScript। proprietary इंजन छोड़ने वाली ज़्यादातर टीमों के लिए, Godot हर काम के लिए सबसे करीबी विकल्प है। आमने-सामने की तुलना के लिए Godot vs Unity web games के लिए देखें।

Cocos Creator

Cocos Creator एक free एडिटर के साथ एक ओपन-सोर्स (MIT) runtime जोड़ता है। यह 2D और 3D दोनों संभालता है, WebGL, WebGPU और Wasm को सपोर्ट करता है, और WeChat और TikTok जैसे mini-game प्लेटफ़ॉर्म के लिए खासतौर पर मज़बूत है जहां build size अहम होता है। Builds करीब 2 से 4 MB के बनते हैं।

Web के लिए 3D लाइब्रेरी और इंजन

Three.js

Three.js web पर सबसे ज़्यादा इस्तेमाल होने वाली 3D लाइब्रेरी है, MIT लाइसेंस वाली, जिसका core करीब 150 KB है। यह एक पूरे इंजन के बजाय एक rendering लाइब्रेरी है, इसलिए आप इसके ऊपर अपने game systems या एक framework जोड़ते हैं। यही trade-off है: ज़्यादा से ज़्यादा कंट्रोल और सबसे छोटा footprint, बदले में खुद ज़्यादा लिखना पड़ता है। हमने Cinevva Engine को इसी की नींव पर बनाया है, game systems को वापस layer करके, ताकि आप खाली canvas से शुरू न करें।

Babylon.js

Babylon.js एक पूरा ओपन-सोर्स 3D इंजन (Apache 2.0) है जिसमें built-in physics, animation, एक scene inspector, और मज़बूत WebGPU और WGSL सपोर्ट है। Three.js के मुकाबले यह आपको ज़्यादा चीज़ें out of the box देता है, बड़े size पर। आपके प्रोजेक्ट के लिए कौन सा सही है, यह जानने के लिए Three.js vs Babylon.js देखें।

2D frameworks

Phaser

Phaser सबसे लोकप्रिय ओपन-सोर्स HTML5 game framework है, MIT लाइसेंस वाला, सबसे बड़े 2D web कम्युनिटी और ecosystem के साथ। Builds करीब 500 KB के होते हैं। अगर आपका गेम 2D है और आप JavaScript लिखते हैं, तो इसे हराना मुश्किल है।

PixiJS

PixiJS एक तेज़ 2D WebGL renderer (MIT) है, करीब 200 KB का। 3D के लिए Three.js की तरह, यह एक पूरे इंजन के बजाय एक renderer है, इसलिए आप अपना game logic खुद लाते हैं। इसे तब चुनें जब आप कस्टम 2D rendering और एक बहुत छोटा footprint चाहते हों।

Excalibur.js

Excalibur.js एक दोस्ताना, BSD-लाइसेंस वाला 2D इंजन है जो TypeScript में लिखा गया है, करीब 300 KB का, जिसमें एक बेसिक renderer से ज़्यादा built-in game फ़ीचर हैं। अगर आप types और एक आसान शुरुआत चाहते हैं तो यह अच्छा फ़िट है।

LÖVE (Love2D)

LÖVE एक पुराना, zlib-लाइसेंस वाला 2D framework है जिसे Lua में script किया जाता है। यह डेस्कटॉप पर तेज़ prototyping और game jams के लिए पसंदीदा है। love.js के ज़रिए web export मौजूद है पर सीमित है, इसलिए LÖVE को एक desktop-first टूल की तरह लें।

Rust, C++ और बड़े पैमाने के इंजन

Bevy

Bevy एक आधुनिक, data-driven इंजन है जो Rust में लिखा गया है, MIT और Apache 2.0 के तहत dual-licensed। इसकी entity-component-system आर्किटेक्चर एक बड़ा आकर्षण है, और यह browser builds के लिए WebAssembly में compile होता है। यह बाकियों से नया है और तेज़ी से बदलता है, इसलिए versions के बीच breaking changes की उम्मीद रखें, पर 2026 में इसकी गति मज़बूत है।

Open 3D Engine (O3DE)

O3DE एक Linux Foundation प्रोजेक्ट (Apache 2.0) है जो बड़े पैमाने के, high-fidelity 3D के लिए बना है, और इसे AWS तथा अन्य कंपनियों का सहारा है। यह AAA महत्वाकांक्षाओं और उससे मेल खाते संसाधनों वाली टीमों के लिए एक गंभीर, भारी इंजन है। यह browser को target नहीं करता।

कैसे चुनें

• लगभग हर चीज़ के लिए एक free इंजन चाहते हैं? Godot।
• एक 2D web game बना रहे हैं? Phaser, या कस्टम rendering के लिए PixiJS/Excalibur.js।
• Web 3D बना रहे हैं? कंट्रोल और size के लिए Three.js, सब कुछ साथ चाहिए तो Babylon.js।
• जितना हो सके छोटा web build? Defold।
• Mini-game प्लेटफ़ॉर्म को target कर रहे हैं? Cocos Creator।
• Rust और ECS पसंद है? Bevy।
• बड़े पैमाने का, high-fidelity 3D? O3DE।

अगर web आपका target है, तो ऊपर के हर इंजन में से O3DE और (ज़्यादातर) LÖVE को छोड़कर हर इंजन एक browser build ship कर सकता है। खासतौर पर web के लिए पूरे विश्लेषण के लिए, web game इंजन की तुलना और हमारी web games के लिए Unity विकल्प की गाइड देखें।

आम सवाल

2026 में सबसे बेहतरीन ओपन-सोर्स गेम इंजन कौन सा है?

ज़्यादातर लोगों के लिए यह Godot है: MIT लाइसेंस वाला, बिना किसी revenue cap के free, और एक साफ़ web export के साथ 2D और 3D दोनों में सक्षम। खासतौर पर 2D web के लिए, Phaser सबसे लोकप्रिय ओपन-सोर्स विकल्प है, और web 3D के लिए यह Three.js (एक लाइब्रेरी) या Babylon.js (एक पूरा इंजन) है। सबसे अच्छा विकल्प dimensions, भाषा और प्लेटफ़ॉर्म पर निर्भर करता है।

क्या Godot सचमुच free है, बिना किसी पेच के?

हां। Godot MIT लाइसेंस के तहत जारी होता है, जिसका मतलब है कभी कोई फीस नहीं, कोई royalty नहीं, कोई revenue थ्रेशोल्ड नहीं, और कोई seat नहीं। आप इसे commercial games के लिए इस्तेमाल कर सकते हैं और इंजन को खुद भी modify कर सकते हैं। यह प्रोजेक्ट डेवलपरों से चार्ज करके नहीं, बल्कि donations और sponsorships से चलता है।

क्या ओपन-सोर्स गेम इंजन commercial games के लिए काफ़ी अच्छे हैं?

हां। बहुत से commercially सफल games ओपन-सोर्स इंजन पर ship होते हैं, और ओपन सोर्स का मतलब है कि किसी revenue cap की चिंता नहीं। trade-offs आमतौर पर एक छोटा built-in asset marketplace होते हैं, और कुछ इंजन के लिए, एक बड़े proprietary इंजन के मुकाबले कम तैयार-मिले फ़ीचर। खासकर web games के लिए, ओपन-सोर्स इंजन अक्सर छोटे, तेज़ builds बनाते हैं।

क्या Unity या Unreal ओपन सोर्स हैं?

नहीं। Unity closed-source और subscription-आधारित है। Unreal Engine source-available है (एक account के साथ आप कोड पढ़ और modify कर सकते हैं) पर यह ओपन सोर्स नहीं है और एक revenue थ्रेशोल्ड से ऊपर royalty मॉडल इस्तेमाल करता है। अगर आपको खासतौर पर एक ओपन-सोर्स इंजन चाहिए, तो Godot Unity का सबसे करीबी विकल्प है, और हमारी Unity विकल्प गाइड बाकी को कवर करती है।

Web के लिए कौन सा ओपन-सोर्स गेम इंजन सबसे अच्छा है?

हर काम के 2D/3D इंजन के लिए Godot, 2D के लिए Phaser, और 3D के लिए Three.js या Babylon.js। किसी भी पूरे इंजन में से Defold सबसे छोटे web builds ship करता है। ये सभी free और ओपन सोर्स हैं। हमारी web game इंजन की तुलना इन्हें build size, load time और browser सपोर्ट के आधार पर रैंक करती है।

संबंधित

• 2026 के लिए सबसे बेहतरीन Web Game इंजन (तुलना) — build size, load time और कीमत के आधार पर रैंक किए गए
• Web Games के लिए Unity विकल्प — Unity छोड़ने वाली टीमों के लिए ओपन-सोर्स विकल्प
• Godot vs Unity Web Games के लिए — सबसे करीबी ओपन-सोर्स विकल्प, आमने-सामने
• 2026 के लिए सबसे बेहतरीन 2D Game इंजन — अगर आपका गेम 2D है
• Three.js vs Babylon.js — दो बड़ी ओपन-सोर्स web 3D लाइब्रेरी
• Cinevva Engine — हमारा ओपन-सोर्स, web-first इंजन जो Three.js पर बना है

Unity web पर export कर सकता है, लेकिन इसके WebGL builds भारी होते हैं, इसकी pricing ने 2023 से developers को झटके दिए हैं, और एक browser-first game के लिए यह शायद ही सबसे हल्का रास्ता है। अगर आप खास web games के लिए Unity का कोई विकल्प ढूँढ रहे हैं, तो यह guide उन engines को कवर करती है जो 2026 में असल में छोटे, तेज़ browser builds बनाते हैं, और इस आधार पर कि आप Unity क्यों छोड़ रहे हैं, किसे चुनना चाहिए।

अगर आप पूरा मैदान साथ-साथ देखना चाहते हैं, तो हमारी 2026 के सबसे अच्छे web game engines की तुलना से शुरू करें। यह पेज खास तौर पर web के लिए Unity की जगह लेने के मामले के लिए है।

Developers Unity के विकल्प क्यों ढूँढते हैं

कुछ वजहें बार-बार सामने आती हैं:

• Pricing पर भरोसा। Unity Runtime Fee सितंबर 2024 में रद्द कर दी गई थी और वापस नहीं आई है, लेकिन इसने कई teams को इस सवाल के इर्द-गिर्द योजना बनाना सिखा दिया कि "अगर terms फिर बदल गए तो?" एक ऐसा engine जिसके license की कीमत दोबारा नहीं रखी जा सकती, वह यह जोखिम हटा देता है।
• Web build size। Unity के खाली WebGL builds करीब 8 से 11 MB से शुरू होते हैं। Web-native engines 1 से 5 MB की रेंज में आते हैं, जिसे players load time में सीधे महसूस करते हैं।
• Mobile browser support। Phones पर Unity WebGL हमेशा से नाज़ुक रहा है। Web के लिए बने हल्के engines mobile Safari और Chrome पर बेहतर चलते हैं।
• Open source। कुछ teams ऐसा codebase चाहती हैं जिसे वे बिना किसी vendor के पढ़ सकें, fork कर सकें, और उस पर भरोसा कर सकें।

अच्छी बात: web के लिए विकल्प मज़बूत हैं, और कई हमेशा के लिए मुफ़्त हैं।

तुरंत तुलना

कोई एक "Unity replacement" नहीं है। सही चुनाव इस पर निर्भर करता है कि आपको 3D चाहिए या नहीं, आप code लिखते हैं या नहीं, और Unity आपके लिए क्यों काम नहीं कर रहा था।

Godot: सबसे करीबी हर-तरफ़ा विकल्प

Godot वह विकल्प है जिस पर ज़्यादातर पूर्व-Unity developers आ टिकते हैं। यह एक पूरा 2D और 3D engine है, MIT license के तहत मुफ़्त, बिना seats, royalties, या revenue caps के, और इसका web export ठोस है। Build size Brotli के साथ compress करके करीब 5 MB होता है, जो Unity के default से छोटा है। Godot 4.3 के बाद से आप single-threaded web builds export कर सकते हैं जो SharedArrayBuffer की ज़रूरत हटा देते हैं, जिसने पुरानी iOS और Safari playback दिक्कतें भी ठीक कर दीं।

Web के लिए एक अड़चन: Godot के C# (.NET) projects अभी browser पर export नहीं हो सकते, सिर्फ़ GDScript होता है। अगर आप कोई C# codebase ले जा रहे हैं, तो यह मायने रखता है। हम Godot बनाम Unity for web games में इन समझौतों को विस्तार से कवर करते हैं।

Godot चुनें अगर आप सबसे Unity-जैसा हर-तरफ़ा engine चाहते हैं, हमेशा के लिए मुफ़्त, एक साफ़ 2D और 3D web रास्ते के साथ।

PlayCanvas: editor के साथ web-first 3D

PlayCanvas पहले दिन से browser के लिए बनाया गया था। इसका runtime लगभग 1 से 2 MB है, यह WebGL2 और WebGPU दोनों को support करता है, और इसका एक collaborative cloud editor है जो आपको जाना-पहचाना लगेगा अगर आपको Unity का scene workflow पसंद था। Games को JavaScript में script किया जाता है। यह एक मज़बूत चुनाव है जब आपको browser में real-time 3D चाहिए और code-only library के बजाय एक visual editor चाहिए।

PlayCanvas चुनें अगर आप Unity-style 3D scene editing चाहते हैं पर एक छोटा web build।

Three.js और Cinevva: अधिकतम control, सबसे छोटा footprint

अगर आप सबसे हल्का संभव web build और rendering पर पूरा control चाहते हैं, तो Three.js मानक है। Core library करीब 150 KB है और यह web पर 3D के एक बड़े हिस्से को चलाती है। यह एक पूरे engine के बजाय एक rendering library है, इसलिए आप अपने game systems या उसके ऊपर एक framework खुद लाते हैं।

ठीक इसी वजह से हमने Cinevva Engine को Three.js पर बनाया: open-source, web-first, game systems ऊपर से जुड़े हुए ताकि आप एक खाली canvas से शुरू न करें। एक codebase browser, mobile, desktop, Steam, और Discord तक पहुँचता है। कोई seats नहीं, कोई install fees नहीं, कोई ऐसे terms नहीं जो आपके game बनाने के बाद बदल जाएँ, जो वही चीज़ है जिसकी Runtime Fee वाले मामले ने लोगों को परवाह करने पर मजबूर किया।

Three.js या Cinevva चुनें अगर आप web-native 3D, open source, और सबसे छोटा footprint चाहते हैं, और आप JavaScript या TypeScript में सहज हैं।

Defold: सबसे छोटे, सबसे तेज़ 2D web builds

Defold किसी भी पूरे engine के सबसे छोटे web builds बनाता है, करीब 1.14 MB, और तेज़ load होता है। यह 2D और हल्का 3D करता है, Lua में script करता है, और बिना किसी revenue thresholds के मुफ़्त है। अगर आपका Unity game 2D है और load time प्राथमिकता है, तो web पर Defold को मात देना मुश्किल है।

Defold चुनें casual और mobile web games के लिए जहाँ हर kilobyte मायने रखता है।

Cocos Creator: mini-games और एशियाई बाज़ार

Cocos Creator एक पूरा 2D और 3D engine है जिसमें WebGL, WebGPU, और Wasm support है, builds 2 से 4 MB की रेंज में बनते हैं, और TypeScript में script होते हैं। यह खास तौर पर mini-game platforms (WeChat, TikTok, Taobao) के लिए मज़बूत है जहाँ Unity का size काम ही नहीं आता। यह मुफ़्त है।

Cocos Creator चुनें mini-games के लिए या अगर आप एशियाई web ecosystem को निशाना बना रहे हैं।

Phaser: 2D web मानक

अगर आपका game 2D है और आप JavaScript लिखते हैं, तो Phaser सबसे लोकप्रिय HTML5 game framework है, जिसमें सबसे बड़ी community और ecosystem है। Builds करीब 500 KB के होते हैं। यह MIT license के तहत मुफ़्त है। 2D web games के लिए यह अक्सर Unity से बेहतर फिट बैठता है, जितना Unity कभी रहा ही नहीं। यह Defold, Construct, और GDevelop से कैसे तुलना करता है, यह देखने के लिए 2026 के सबसे अच्छे 2D game engines देखें।

Phaser चुनें 2D web games के लिए जब आप code, community, और एक छोटा build चाहते हैं।

Construct और GDevelop: code के बिना Unity छोड़ना

अगर Unity से आपकी झुंझलाहट का एक हिस्सा code और setup की मात्रा थी, तो visual engines एक असली विकल्प हैं। Construct और GDevelop दोनों बिना किसी programming के 2D games बनाते हैं और साफ़ web builds export करते हैं। GDevelop का एक मुफ़्त tier है और यह open-source-friendly है; Construct एक subscription पर आधारित है जिसमें एक पॉलिश किया हुआ editor है।

इनमें से एक चुनें अगर आप थोड़े या बिना code के web games को visually बनाना चाहते हैं।

कैसे चुनें, Unity छोड़ने की वजह के हिसाब से

• Pricing या भरोसे की वजह से छोड़ा? open source की ओर जाएँ: Godot, Defold, Phaser, Three.js, या Cinevva। इनमें से किसी की कीमत आपके नीचे से दोबारा नहीं रखी जा सकती।
• Browser में 3D चाहिए? PlayCanvas (editor के साथ) या Three.js और Cinevva (control और सबसे छोटे size के लिए)।
• 2D बना रहे हैं? सबसे छोटे builds के लिए Defold, सबसे बड़ी community के लिए Phaser।
• Code नहीं लिखना चाहते? Construct या GDevelop।
• Mini-game platforms को निशाना बना रहे हैं? Cocos Creator।

आप जो भी चुनें, web छोटे builds और तेज़ loads को इनाम देता है। एक बार चुन लेने के बाद, तेज़ load होने वाला web game ship करें देखें।

आम सवाल

Web games के लिए सबसे अच्छा Unity विकल्प कौन सा है?

ज़्यादातर teams के लिए यह Godot है: एक मुफ़्त, open-source, पूरा 2D और 3D engine जिसके web builds Unity से छोटे होते हैं और iOS व Safari के लिए एक साफ़ single-threaded export रास्ता होता है। अगर आपको खास तौर पर browser-first 3D चाहिए, तो PlayCanvas या Three.js और भी हल्के हैं। सबसे अच्छा चुनाव इस पर निर्भर करता है कि आपको 3D चाहिए या नहीं और आप code लिखते हैं या नहीं।

क्या Unity का कोई मुफ़्त विकल्प है?

हाँ, कई हैं। Godot, Defold, Phaser, PixiJS, Excalibur.js, और Three.js सभी मुफ़्त और open-source हैं, बिना किसी revenue caps या seat fees के। Cocos Creator और GDevelop के भी मुफ़्त विकल्प हैं। खास तौर पर web games के लिए, ये मुफ़्त engines अक्सर Unity से छोटे, तेज़ builds बनाते हैं।

Web games के लिए Unity से क्यों स्विच करें?

आम वजहें हैं build size (Unity के खाली WebGL builds करीब 8 से 11 MB से शुरू होते हैं बनाम web-native engines के लिए 1 से 5 MB), mobile browser विश्वसनीयता, 2023 के Runtime Fee वाले मामले के बाद pricing पर भरोसा, और open source की पसंद। अगर web आपका मुख्य लक्ष्य है, तो एक web-first engine आमतौर पर बेहतर नतीजा देता है।

क्या मैं Unity को एक open-source engine से बदल सकता हूँ?

हाँ। आम 2D और 3D के लिए Godot सबसे करीबी open-source समकक्ष है, और यह MIT license वाला है, बिना किसी fees के। Web-native 3D के लिए, Three.js (और Cinevva जैसे इस पर बने engines) भी open source हैं। मुख्य migration लागत एक नई language में फिर से बनाना है, क्योंकि हर engine का अपना scripting होता है।

किस Unity विकल्प का सबसे छोटा web build है?

पूरे engines में, Defold सबसे छोटा है, करीब 1.14 MB पर। एक library के तौर पर Three.js और भी छोटा है, करीब 150 KB के core के साथ, हालाँकि आप अपना game code खुद जोड़ते हैं। Godot compress करके करीब 5 MB पर आता है, फिर भी Unity के 8 MB-प्लस शुरुआती बिंदु से काफ़ी नीचे।

संबंधित

• 2026 के सबसे अच्छे Web Game Engines (तुलना किए गए) — पूरा मैदान, रैंक किया हुआ
• 2026 के सबसे अच्छे Open-Source Game Engines — मुफ़्त, खुद-fork-करो विकल्प एक जगह
• Web Games के लिए Godot बनाम Unity — सबसे करीबी विकल्प, आमने-सामने
• Unity Runtime Fee रद्द: आधिकारिक कहानी — pricing पर भरोसा एक तय करने वाला कारक क्यों बना
• 2026 के सबसे अच्छे 2D Game Engines — अगर आपका game 2D है
• PlayCanvas बनाम Three.js — web 3D के लिए engine बनाम library
• Cinevva Engine — हमारा open-source, web-first engine जो Three.js पर बना है

2D 2026 में पूरी तरह जिंदा है, और आपके पास पहले से कहीं ज्यादा अच्छे इंजन हैं। सही इंजन इस पर निर्भर करता है कि आप कोड लिखते हैं या नहीं, आप web पर शिप कर रहे हैं या नहीं, और आपको बिल्ड कितना छोटा चाहिए। यहां मुख्य विकल्पों की तुलना है, और हर एक किसके लिए सही है।

अगर आप 3D या पूरे cross-platform इंजन भी तौल रहे हैं, तो ज्यादा विस्तृत web game engines तुलना देखें।

क्विक रेफरेंस

इंजन

Godot

ओपन-सोर्स का पसंदीदा, और सचमुच एक बेहतरीन 2D इंजन। Godot 4.7 (जून 2026) में एक डेडिकेटेड 2D रेंडरर, एक हल्का एडिटर, और शुरुआती लोगों के लिए आसान GDScript है। यह MIT लाइसेंस के तहत फ्री है, बिना किसी रॉयल्टी के। Web export WebGL2 पर मजबूत है, बस इतना ध्यान रहे कि browser में सिर्फ GDScript export होता है, C# नहीं। अगर आप एक फ्री टूल चाहते हैं जो शानदार 2D और ठीक-ठाक 3D दोनों करे, तो यही डिफॉल्ट विकल्प है।

किसके लिए सबसे अच्छा: ऑल-राउंड 2D, ओपन-सोर्स प्रोजेक्ट, pixel art।

GameMaker

Undertale जैसे हिट और कमर्शियल 2D games की लंबी कतार के पीछे का इंजन। यह GML इस्तेमाल करता है, इसकी अपनी तेज स्क्रिप्टिंग भाषा, और फ्री टियर पर भी HTML5 export देता है। कीमत एक दोस्ताना मॉडल में बदल गई है: गैर-कमर्शियल इस्तेमाल के लिए फ्री और कमर्शियल काम के लिए एक बार का $99.99 Pro लाइसेंस, सब्सक्रिप्शन की जगह।

किसके लिए सबसे अच्छा: कमर्शियल 2D जहां आप तेजी से शिप करना चाहते हैं, pixel art।

Construct

एक browser-based, no-code इंजन जो एक event सिस्टम के इर्द-गिर्द बना है। आप games को विज़ुअली बनाते हैं, बिना किसी प्रोग्रामिंग के, और चूंकि यह HTML5-native है, web export बढ़िया रहता है। कीमत सब्सक्रिप्शन पर आधारित है, टियर के हिसाब से लगभग $5 से $39 प्रति महीना, साथ में एक सीमित फ्री विकल्प।

किसके लिए सबसे अच्छा: शुरुआती, no-code क्रिएटर, और web-first 2D।

Defold

पूर्व King डेवलपर्स का बनाया एक फ्री इंजन जो हैरान कर देने वाले छोटे web बिल्ड बनाता है, अक्सर 2 MB gzipped से कम। इससे यह उन casual web games और मिनी-गेम प्लेटफॉर्म के लिए आदर्श बनता है जहां लोड टाइम ही सब कुछ है। यह Lua इस्तेमाल करता है और Defold License के तहत source-available है।

किसके लिए सबसे अच्छा: सबसे छोटे, सबसे तेज लोड होने वाले web games।

Phaser

सबसे लोकप्रिय HTML5 गेम framework, और एक code-first वाला। Phaser 4 (अप्रैल 2026 में रिलीज) एक नया WebGL रेंडरर लेकर आया जो पूरी तरह नए सिरे से बनाया गया था। यह फ्री और ओपन-सोर्स है, आप JavaScript या TypeScript लिखते हैं, और चूंकि यह एक web framework है इसलिए कोई "export" स्टेप नहीं है, आपका गेम पहले से ही browser में चलता है।

किसके लिए सबसे अच्छा: ऐसे डेवलपर जो code-first, web-native 2D framework चाहते हैं।

GDevelop

ओपन-सोर्स और no-code, GDevelop आसपास के सबसे शुरुआती-फ्रेंडली इंजनों में से एक है। यह फ्री है, साथ में $5 प्रति महीने से एक वैकल्पिक प्रीमियम टियर, और यह असीमित HTML5 बिल्ड export करता है। अगर आप no-code चाहते हैं पर साथ में ओपन-सोर्स भी, तो यह एक अच्छा बीच का रास्ता है।

किसके लिए सबसे अच्छा: फ्री no-code 2D।

Unity

Unity का 2D टूलसेट परिपक्व है, और इसका ecosystem और asset store बेमिसाल है। एक छोटे 2D गेम के लिए यह जरूरत से ज्यादा है, लेकिन अगर आप cross-platform पहुंच चाहते हैं या आगे चलकर 3D में बढ़ने की सोच रहे हैं, तो यह अपनी जगह बना लेता है। $200K रेवेन्यू से कम पर Personal फ्री है, Pro करीब $2,200 प्रति साल प्रति सीट है। Godot से अलग, Unity का C# web पर export होता है।

किसके लिए सबसे अच्छा: ऐसी टीमें जो ecosystem या cross-platform पहुंच चाहती हैं।

LÖVE (Love2D)

एक मिनिमलिस्ट Lua framework, पूरा एडिटर नहीं। आप कोड लिखते हैं, यह चलता है। LÖVE 11.5 मौजूदा स्टेबल रिलीज है, और 12.0 डेवलपमेंट में है। Web export थर्ड-पार्टी love.js के जरिए मौजूद है, लेकिन यह first-class नहीं है। LÖVE तब चुनें जब आपको कोड लिखना पसंद हो और आप अपने और game loop के बीच लगभग कोई abstraction न चाहते हों।

किसके लिए सबसे अच्छा: code-focused हॉबीइस्ट और हल्के प्रोटोटाइप।

कैसे चुनें

• आप कोड नहीं लिखना चाहते: Construct या GDevelop। अगर आप web पर शिप कर रहे हैं तो Construct, अगर आप ओपन-सोर्स चाहते हैं तो GDevelop।
• आपको सबसे छोटा, सबसे तेज web बिल्ड चाहिए: Defold।
• आप कोड लिखते हैं और web को टारगेट करते हैं: Phaser।
• आप हर चीज के लिए एक फ्री इंजन चाहते हैं: Godot।
• आप एक कमर्शियल 2D गेम शिप कर रहे हैं: GameMaker या Unity।
• आपको सबसे बड़ा ecosystem चाहिए या आप 3D जोड़ने की योजना बना रहे हैं: Unity।

आप जो भी चुनें, आपको art और audio की जरूरत होगी। ऐसे स्रोतों के लिए फ्री गेम एसेट्स कहां मिलेंगी देखें जिन्हें आप सीधे डाल सकते हैं।

आम सवाल

2026 में सबसे अच्छा 2D गेम इंजन कौन सा है?

ज्यादातर लोगों के लिए, Godot सबसे अच्छा ऑल-राउंड 2D इंजन है: फ्री, ओपन-सोर्स, एक first-class 2D रेंडरर के साथ। अगर आप कोड नहीं लिखना चाहते, तो Construct (web-first) या GDevelop (ओपन-सोर्स) बेहतर हैं। कमर्शियल 2D के लिए, GameMaker और Unity आजमाए हुए हैं। "सबसे अच्छा" इस पर निर्भर करता है कि आप कोड लिखते हैं या नहीं और आप कहां शिप कर रहे हैं।

शुरुआती लोगों के लिए कौन सा 2D गेम इंजन सबसे अच्छा है?

Construct और GDevelop सबसे शुरुआती-फ्रेंडली हैं क्योंकि वे no-code हैं, आप प्रोग्रामिंग की जगह विज़ुअल event सिस्टम से बनाते हैं। GDevelop फ्री और ओपन-सोर्स है, Construct सब्सक्रिप्शन पर आधारित है पर इसका web export सबसे आसान है। अगर आप साथ-साथ कोड लिखना सीखना चाहते हैं, तो GDScript वाला Godot code-based इंजनों में सबसे आसान है।

सबसे अच्छा फ्री 2D गेम इंजन कौन सा है?

Godot सबसे मजबूत फ्री, ओपन-सोर्स 2D इंजन है, बिना किसी फीस या रॉयल्टी के। GDevelop सबसे अच्छा फ्री no-code विकल्प है, Defold सबसे छोटे web बिल्ड के साथ फ्री है, और Phaser एक फ्री ओपन-सोर्स framework है अगर आप कोड लिखते हैं। GameMaker गैर-कमर्शियल इस्तेमाल के लिए फ्री है, फिर कमर्शियल प्रोजेक्ट के लिए एक बार का $99.99 लाइसेंस।

कौन सा 2D इंजन सबसे छोटे web games बनाता है?

Defold सबसे छोटे web बिल्ड बनाता है, अक्सर 2 MB gzipped से कम, इसीलिए यह उन casual और मिनी-गेम प्लेटफॉर्म के लिए लोकप्रिय है जहां लोड टाइम तय करता है कि खिलाड़ी टिकेंगे या नहीं। Phaser और Godot भी ठीक-ठाक हैं, लेकिन कच्चे footprint के मामले में Defold आगे है।

संबंधित

• 2026 के लिए सबसे अच्छे Web Game Engines (तुलना) — 2D और 3D, पूरा मैदान
• Web Games के लिए Godot बनाम Unity — दो बड़े इंजन आमने-सामने
• Construct बनाम GDevelop — दो no-code 2D इंजनों की तुलना
• फ्री गेम एसेट्स कहां मिलेंगी — आपके 2D गेम के लिए art और audio
• Canvas 2D game loop — बिना किसी इंजन के एक 2D गेम बनाएं
• Cinevva Engine — हमारा ओपन-सोर्स, web-first इंजन

अगर आप कोड लिखे बिना एक game बनाना चाहते हैं, तो ये दोनों सबसे आगे हैं। दोनों programming के बजाय visual event logic से games बनाते हैं, और दोनों web पर export करते हैं। बड़ा फर्क सोच और कीमत का है: Construct एक polished subscription product है, GDevelop free और open source है। 2026 में ये कैसे तुलना करते हैं, यहाँ देखिए।

code-based इंजनों समेत बड़े मैदान के लिए, web game engines की तुलना और 2026 के सबसे अच्छे 2D game engines देखें।

झटपट फैसला

No-Code, दो तरीके

दोनों इंजन आपको visual conditions और actions को जमाकर एक game बनाने देते हैं, कोई programming की जरूरत नहीं। Construct "event sheets" का इस्तेमाल करता है, एक साफ-सुथरा, spreadsheet जैसा flow जिसकी इस बात के लिए खूब तारीफ होती है कि आप इसमें कितनी तेजी से prototype बना सकते हैं। GDevelop एक मिलते-जुलते event system का इस्तेमाल करता है और शुरुआती लोगों के लिए उतना ही आसान है।

सबसे जरूरी फर्क: Construct एक paid, closed-source product है; GDevelop free और MIT license के तहत open source है। अगर open source या जीरो कीमत आपकी प्राथमिकता है, तो शायद यही अकेली बात फैसला कर दे।

कीमत

Construct 3 एक subscription पर चलता है। एक सीमित free edition है, और Personal plan लगभग $15.99 प्रति माह या $129.99 प्रति साल है, इससे ऊपर Education और Business tiers हैं। आप एक polished, सक्रिय रूप से विकसित होते product के लिए भुगतान कर रहे हैं।

GDevelop का इंजन free और open source है। वैकल्पिक premium tiers (लगभग $7.99 Silver, $13.99 Gold, और $39.99 Pro प्रति माह, सालाना billing करीब 40% सस्ती) cloud builds और online services जोड़ते हैं, लेकिन आप पूरी तरह free में games बना और export कर सकते हैं। जनवरी 2026 में नए subscribers के लिए कीमतें 20% बढ़ीं (मौजूदा subscribers की कीमत पहले जैसी बनी रही)।

किसी शौकिया या कीमत को लेकर सजग किसी भी इंसान के लिए, GDevelop के free tier के खिलाफ तर्क देना मुश्किल है। एक ऐसे studio के लिए जो एक परिष्कृत commercial tool चाहता है, Construct का subscription वाजिब है।

3D, Scripting, और Multiplayer

3D: GDevelop यहाँ आगे निकल गया। इसके 5.6 release (दिसंबर 2025) ने Jolt-आधारित physics, shadows, animated models, 3D particles, और तैयार character तथा vehicle behaviors के साथ एक पूरा real-time 3D editor दिया, और बाद के 5.6 updates ने 3D point और spot lights भी जोड़े। Construct पीछा कर रहा है: r487 stable release (मई 2026) ने अपने पहले से मौजूद 3D camera और glTF model सपोर्ट के ऊपर gizmos वाला 3D editor mode और एक 3D bullet behavior जोड़ा। यह एक असली कदम है, लेकिन यह अब भी मूल रूप से एक 2D इंजन के ऊपर बना है।

Scripting: जब events आपके लिए कम पड़ने लगें, तो दोनों आपको code में उतरने देते हैं। Construct event sheets के साथ-साथ JavaScript और TypeScript को सपोर्ट करता है। GDevelop अपने events और extensions के जरिए JavaScript को सपोर्ट करता है। दोनों no-code रास्ते को मुख्य रखते हैं।

Multiplayer: Construct peer-to-peer games के लिए WebRTC data channels पर एक built-in Multiplayer object देता है। GDevelop अपनी online services के जरिए built-in lobby-आधारित multiplayer देता है, जिसमें free plan एक 4-player lobby तक सीमित है और paid plans इसे 8 तक बढ़ा देते हैं।

कब किसे चुनें

GDevelop चुनें अगर आप free और open source, cross-platform export, और ज्यादा सक्षम real-time 3D editor चाहते हैं। यह शौकीनों, छात्रों, और किसी भी ऐसे इंसान के लिए ज्यादा सही है जो अपनी tooling का मालिक रहना चाहता है।

Construct चुनें अगर आप सबसे polished event-sheet workflow, परिपक्व और भरोसेमंद HTML5 export, और built-in WebRTC multiplayer चाहते हैं, और आपको एक परिष्कृत commercial product के लिए subscription से ऐतराज नहीं है।

चाहे जो भी हो, आपको art और audio चाहिए होगा। ऐसे sources के लिए जो आप तुरंत इस्तेमाल कर सकते हैं, free game assets कहाँ मिलें देखें।

आम सवाल

शुरुआती लोगों के लिए Construct बेहतर है या GDevelop?

दोनों शुरुआती लोगों के लिए बनाए गए हैं और बिना किसी coding के visual event logic का इस्तेमाल करते हैं। GDevelop कीमत पर जीतता है (यह free और open source है) और अब इसका 3D editor ज्यादा मजबूत है। Construct workflow की चमक और built-in multiplayer पर जीतता है। अगर बजट मायने रखता है, तो GDevelop से शुरू करें। अगर आप सबसे परिष्कृत 2D event workflow चाहते हैं, तो पहले Construct का free edition आजमाएँ।

क्या GDevelop सच में free है?

हाँ। GDevelop इंजन MIT license के तहत free और open source है, और आप बिना किसी कीमत के HTML5 games बना और export कर सकते हैं। वैकल्पिक premium tiers (लगभग $7.99/माह से) cloud builds और online services जोड़ते हैं, लेकिन एक game बनाने और भेजने के लिए ये जरूरी नहीं हैं।

क्या Construct और GDevelop 3D games बना सकते हैं?

दोनों के पास 3D है, लेकिन GDevelop ज्यादा आगे है। GDevelop 5.6 (दिसंबर 2025) ने physics, shadows, और animated models के साथ एक पूरा real-time 3D editor जोड़ा। Construct ने r487 (मई 2026) में अपने 3D camera और glTF model सपोर्ट के साथ-साथ अपना खुद का 3D editor mode जोड़ा, लेकिन यह मुख्य रूप से एक 2D इंजन ही बना रहता है। 3D की ओर झुके projects के लिए, GDevelop ज्यादा मजबूत no-code विकल्प है।

क्या Construct और GDevelop web पर export करते हैं?

हाँ, दोनों HTML5 games export करते हैं जो browser में चलते हैं। Construct HTML5-native है और परिपक्व, भरोसेमंद web export देता है। GDevelop असीमित HTML5 builds export करता है, free में locally भी। दोनों browser games के लिए ठोस विकल्प हैं।

संबंधित

• 2026 के सबसे अच्छे 2D Game Engines — पूरा 2D मैदान, code और no-code
• 2026 के सबसे अच्छे Web Game Engines (तुलना) — 2D और 3D
• Free Game Assets कहाँ मिलें — आपके game के लिए art और audio
• itch.io पर अपना Game कैसे लॉन्च करें — अपने game को players के सामने लाना
• Cinevva — AI-powered tools से games बनाएँ, web-first

Godot और Unity दोनों एक game को browser तक पहुँचा सकते हैं। वे वहाँ बहुत अलग तरीकों से पहुँचते हैं, और खास web के लिए इन दोनों के बीच का फ़र्क आम "Godot बनाम Unity" बहस के मुकाबले कहीं ज़्यादा तीखा है। यह guide उन्हीं चीज़ों पर इनकी तुलना करती है जो असल में एक web build तय करती हैं: download size, rendering, language support, mobile browsers, और cost।

अगर आप हर browser engine का बड़ा नज़ारा चाहते हैं, तो हमारी web game engines की तुलना से शुरू करें। यह पेज दो बड़े full-engine विकल्पों पर ज़ूम करता है।

तुरंत फ़ैसला

सबसे बड़ा एक ही तय करने वाला कारक: अगर आपका game C# में लिखा है, तो Unity उसे web पर भेज सकता है और Godot अब भी नहीं कर सकता। बाकी सब कुछ इसी से निकलता है।

Build Size और Load Time

Download size वह पहली चीज़ है जो एक web player को महसूस होती है। Godot का web export engine को एक WebAssembly binary के रूप में भेजता है जो uncompressed लगभग 40 MB है पर Brotli के साथ करीब 5 MB तक compress हो जाता है। यह size इसलिए आता है क्योंकि prebuilt template पूरा engine ढोता है (3D renderer, audio, networking), क्योंकि उसे पता नहीं होता कि आपका game कौन-से features इस्तेमाल करता है।

Unity की खाली web builds, Unity 6 पर Brotli के साथ मापी गईं, एक 2D built-in pipeline project के लिए करीब 7.7 MB और एक 3D URP template के लिए 10.7 MB पर आती हैं। एक आक्रामक तरीके से stripped minimal build करीब 2 MB तक नीचे आ सकती है। तो एक ध्यान से छाँटी गई Unity 2D build Godot के footprint के करीब पहुँच सकती है, पर Godot का default कम मेहनत में ही छोटा होता है।

दोनों engines के लिए, आपके assets आम तौर पर engine binary से कहीं ज़्यादा बड़े होते हैं। textures और audio को compress करें, जो stream कर सकते हैं उसे stream करें, और engine का चुनाव आपके asset budget से कम मायने रखता है।

C# की सीमा (चुनने से पहले इसे पढ़ें)

यही वह बात है जो teams को चौंकाती है। 2026 तक, C# (.NET) में लिखे Godot projects आधिकारिक रूप से web पर export नहीं कर सकते। GDScript ठीक से export होता है। मई 2025 में GodotCon Boston में Mono को statically link करके एक चलता हुआ C# web prototype दिखाया गया था, पर इसने एक बड़ा payload भेजा और team किसी release timeline पर प्रतिबद्ध नहीं हुई।

Unity, इसके उलट, C# को WebAssembly में compile करता है और सालों से C# को browser में भेज रहा है। तो अगर आपके पास पहले से एक C# codebase है, या आपकी team सिर्फ़ C# जानती है, तो web के लिए Unity व्यावहारिक चुनाव है। अगर आप नए सिरे से शुरू कर रहे हैं और GDScript में खुश हैं, तो Godot का web रास्ता साफ़ है।

Rendering: WebGL2 बनाम WebGPU

Godot का web export अपने Compatibility renderer के ज़रिए WebGL2 को target करता है। इसका बड़ा WebGPU काम web export के लिए अभी production-ready नहीं है। Godot 4.5 (सितंबर 2025) ने WebAssembly SIMD ज़रूर जोड़ा, जो बिना code बदले web performance में मदद करता है।

Unity 6 ने एक experimental WebGPU backend जोड़ा जो compute shaders और WebGL2 से आगे के modern GPU features देता है, और WebGL2 अब भी सुरक्षित fallback है। WebGPU अभी हर browser पर उपलब्ध नहीं है (मौजूदा support के लिए हमारी web games tech stack guide देखें), तो इसे एक upgrade रास्ता मानें, baseline नहीं। Unity 6 ने WebAssembly heap को भी 4 GB तक बढ़ाया और Wasm SIMD तथा native exceptions जोड़े।

अगर आपको आज browser में compute shaders या भारी 3D चाहिए, तो Unity का WebGPU रास्ता आगे है। 2D और WebGL2 पर हल्के 3D के लिए, दोनों ठीक हैं।

Threading, iOS, और Hosting की दिक्कतें

Godot 4 को मूल रूप से SharedArrayBuffer चाहिए था, जिसे browsers तभी उजागर करते हैं जब पेज cross-origin isolated हो (COOP और COEP headers)। यह एक hosting दिक्कत है, और itch.io पर यह सिर्फ़ Chrome में काम करता है। Godot 4.3 से आप single-threaded builds export कर सकते हैं जो इस ज़रूरत को पूरी तरह हटा देती हैं, और उसी बदलाव ने पुराने iOS और Safari playback की समस्याएँ भी ठीक कीं। एक web-first Godot game के लिए, single-threaded export आम तौर पर ज़्यादा सुरक्षित default होता है।

Unity की web builds भी WebAssembly इस्तेमाल करती हैं, और mobile web support Unity 6 से शुरू होता है। अगर आप व्यापक mobile browsers को target कर रहे हैं, तो दोनों engines में असली devices पर जल्दी test करें, क्योंकि web builds सबसे पहले वहीं टूटती हैं।

Pricing

Godot MIT license के तहत free है। कोई seats नहीं, कोई royalties नहीं, कोई revenue cap नहीं, कोई fees नहीं, कभी नहीं।

सितंबर 2024 में Runtime Fee रद्द करने के बाद Unity seat-आधारित subscriptions पर लौट आया (वह वापस नहीं आई)। Unity Personal $200K revenue या funding तक free रहता है, और "Made with Unity" splash Unity 6 पर optional हो गया। Unity Pro करीब $2,200 प्रति seat प्रति साल है, और 2026 की शुरुआत में paid tiers में करीब 5% की बढ़ोतरी हुई। cap से नीचे के एक solo dev या छोटी team के लिए, दोनों engines के साथ भेजना असल में free है।

कब क्या चुनें

web के लिए Godot चुनें जब आप एक free, छोटे-footprint वाला 2D या हल्का-3D browser game चाहते हों, single-threaded export के ज़रिए smooth iOS और Safari support चाहते हों, और आप GDScript लिखने में सहज हों।

web के लिए Unity चुनें जब आपको WebGPU के ज़रिए भारी 3D या compute shaders चाहिए, आप बड़ा asset ecosystem चाहते हों, या आप एक C# team हों, और आप बड़ी builds तथा experimental-WebGPU की चेतावनी स्वीकार कर सकते हों।

जो भी हो, आपकी build को फिर भी तेज़ी से load होना और phone पर चलना है। चुनाव कर लेने के बाद एक web game भेजें जो तेज़ी से load हो देखें।

आम सवाल

क्या Godot C# games को web पर export कर सकता है?

2026 तक, आधिकारिक रूप से नहीं। Godot का web export GDScript के लिए काम करता है, पर C# (.NET) projects अभी browser पर export नहीं कर सकते। मई 2025 में GodotCon Boston में एक prototype दिखाया गया था, पर कोई प्रतिबद्ध release तारीख़ नहीं है। अगर आपको web पर C# चाहिए, तो इन दोनों में से फ़िलहाल Unity ही वह है जो इसे भेजता है।

web builds के लिए Godot छोटा है या Unity?

Godot की खाली web build Brotli के साथ करीब 5 MB compressed है। Unity 6 की खाली builds 2D के लिए करीब 7.7 MB और 3D के लिए 10.7 MB पर चलती हैं, हालाँकि आक्रामक तरीके से stripped Unity build करीब 2 MB तक पहुँच सकती है। Godot default रूप से छोटा है, पर एक tuned Unity 2D build करीब आ सकती है। आपके अपने assets आम तौर पर engine binary से ज़्यादा मायने रखते हैं।

क्या Unity browser में WebGPU को support करता है?

हाँ, Unity 6 ने compute shaders और modern GPU features के साथ एक experimental WebGPU backend जोड़ा, और WebGL2 fallback के रूप में है। इसे experimental बताया गया है और यह हर browser पर support नहीं है, तो अपनी baseline के रूप में WebGL2 भेजें और WebGPU को एक बढ़त मानें।

browser games के लिए बेहतर कौन है, Godot या Unity?

अच्छे iOS support के साथ free, हल्के 2D या हल्के 3D games के लिए, Godot ज़्यादा साफ़ web रास्ता है, बशर्ते आप GDScript इस्तेमाल करें। भारी 3D, compute shaders, बड़े ecosystem, या पहले से मौजूद C# codebase के लिए, Unity web पर जीतता है। आम तौर पर C# का सवाल ही इसे तय करता है।

संबंधित

• 2026 के लिए बेहतरीन Web Game Engines (तुलना के साथ) — पूरा मैदान, इन दोनों से आगे
• Web Games के लिए Unity के विकल्प — हर web-सक्षम विकल्प, इस आधार पर चुना गया कि आप Unity क्यों छोड़ रहे हैं
• 2026 के लिए बेहतरीन 2D Game Engines — अगर आपका game 2D है, यहाँ से शुरू करें
• 2026 में Web Games का Tech Stack — WebGL, WebGPU, और Wasm समझाए गए
• एक web game भेजें जो तेज़ी से load हो — build-size और load-time की तरकीबें
• Cinevva Engine — हमारा open-source, web-first engine जो Three.js पर बना है

लोग इन दोनों को प्रतिद्वंद्वियों की तरह आमने-सामने रखते हैं, पर ये एक ही तरह के tool नहीं हैं। PlayCanvas एक visual editor वाला पूरा game engine है। Three.js एक rendering library है जिस पर आप code से चीज़ें बनाते हैं। इन दोनों में से चुनना असल में यह सवाल है कि आप कितना तैयार-तैयार चाहते हैं बनाम कितना control अपने हाथ में चाहते हैं। 2026 में web 3D के लिए यहाँ पूरा ब्योरा है।

बड़े दायरे के लिए, हमारी web game engines की तुलना देखें।

तुरंत फ़ैसला

Engine बनाम Library

पूरी कहानी एक लाइन में यही है। PlayCanvas आपको एक game engine देता है: एक entity-component system, physics, animation, audio, input, और एक asset pipeline, सब आपस में जुड़े हुए, साथ में एक browser-based editor जहाँ एक team मिलकर real time में scene बना सकती है (सोचिए collaborative editing, जैसे 3D के लिए कोई design tool)।

Three.js आपको एक renderer देता है। Scene graph, cameras, lights, materials, और एक तेज़ WebGL/WebGPU renderer। कोई editor नहीं, कोई physics नहीं, game loop के बारे में कोई राय नहीं। आप physics को Rapier या cannon-es जैसी किसी चीज़ से जोड़ते हैं, अपनी game logic खुद बनाते हैं, और जो भी tooling चाहिए वह बनाते हैं। यह आज़ादी है और साथ में ज़्यादा काम भी।

तो असली सवाल "कौन-सा बेहतर है" नहीं है, बल्कि "क्या मुझे engine चाहिए या renderer" है।

Rendering और WebGPU

GPU के मामले में दोनों आधुनिक हैं। PlayCanvas एक dual WebGL2 और WebGPU backend चलाता है। इसके v2.0 release (अगस्त 2024) ने WebGL1 को पूरी तरह हटा दिया, और हाल के engine builds ने 3D Gaussian splats के लिए एक compute-based WebGPU path जोड़ा। Three.js ने r171 के आसपास (सितंबर 2025) एक production-ready WebGPURenderer उतारा, लगभग zero-config setup के साथ और एक automatic WebGL2 fallback के साथ, साथ में TSL (Three.js Shading Language) ताकि आप shaders एक बार लिखें और दोनों backends को target करें।

2026 में ज़्यादातर projects के लिए दोनों में से कोई भी खूबसूरती से render करेगा। WebGPU दोनों पर upgrade का रास्ता है, और WebGL2 सुरक्षित baseline है। मौजूदा browser support के लिए हमारी web games tech stack guide देखें।

Workflow, Licensing, और Cost

PlayCanvas का editor इसकी सबसे बड़ी ख़ासियत है: एक hosted, collaborative scene editor जिसमें एक asset pipeline है। Engine MIT के तहत open source है, और editor frontend भी 2025 में open-source कर दिया गया। Hosted editor के tiers हैं, एक free plan, करीब $15 महीने का Personal plan, और करीब $50 per seat महीने का Organization plan, जो ज़्यादातर storage और private project limits पर अलग होते हैं।

Three.js MIT और मुफ़्त है, बस इतना ही। चुकाने के लिए कोई editor नहीं है क्योंकि editor है ही नहीं। आपकी "cost" वह engineering समय है जिससे आप वह structure बनाते हैं जो PlayCanvas आपको तैयार देता है।

कब किसे चुनें

PlayCanvas तब चुनें जब आपको out of the box एक पूरा engine और एक visual editor चाहिए, आपकी team को scenes पर collaborate करना है, और आप शुरू से बनाने के बजाय configure करना पसंद करते हैं। यह खासकर product configurators, interactive 3D, और तेज़ी से ship करने वाली teams के लिए मज़बूत है।

Three.js तब चुनें जब आपको rendering और architecture पर पूरा control चाहिए, आप अपनी stack खुद इकट्ठी करने में सहज हैं, या आप कुछ ऐसा bespoke बना रहे हैं जहाँ किसी engine की राय बीच में आ जाएगी। यह बड़ा ecosystem भी है और सबसे ज़्यादा माँग वाली web-3D skill भी। हमने ठीक इसी वजह से Cinevva Engine को Three.js पर बनाया: web-first, open, और जो भी customize करना चाहें उस पर कोई सीमा नहीं।

आम सवाल

Web games के लिए PlayCanvas बेहतर है या Three.js?

दोनों में से कोई सख़्ती से बेहतर नहीं है, ये अलग tools हैं। PlayCanvas एक visual editor वाला पूरा engine है, इसलिए एक structured game या interactive app को ship करना तेज़ है, खासकर किसी team के लिए। Three.js एक rendering library है जो आपको पूरा control देती है पर उम्मीद करती है कि आप game systems खुद बनाएँगे। turnkey के लिए PlayCanvas चुनें, custom के लिए Three.js।

क्या Three.js एक game engine है?

नहीं। Three.js एक 3D rendering library है। यह scene graph, cameras, lights, materials, और WebGL2 या WebGPU के ज़रिए rendering संभालती है, पर इसमें कोई built-in physics, audio, input, या game loop नहीं है। आप इन्हें दूसरी libraries (जैसे physics के लिए Rapier) से जोड़ते हैं या खुद बनाते हैं। इसके उलट PlayCanvas एक पूरा engine है।

क्या PlayCanvas और Three.js WebGPU को support करते हैं?

हाँ, 2026 में दोनों करते हैं। PlayCanvas एक dual WebGL2/WebGPU backend चलाता है। Three.js के पास एक production-ready WebGPURenderer है (r171 के आसपास से stable) जिसमें automatic WebGL2 fallback और cross-target shaders के लिए TSL है। WebGL2 को अपना baseline बनाकर ship करें और WebGPU को performance upgrade की तरह लें।

क्या PlayCanvas मुफ़्त है?

PlayCanvas engine MIT license के तहत मुफ़्त और open source है, और editor frontend 2025 में open-source कर दिया गया। Hosted cloud editor का एक free tier है साथ में paid plans (करीब $15/महीना Personal और $50/seat/महीना Organization) जो मुख्य रूप से storage और private projects जोड़ते हैं। Three.js पूरी तरह मुफ़्त है और चुकाने के लिए कोई editor नहीं है।

संबंधित

• 2026 के लिए बेहतरीन Web Game Engines (तुलना के साथ) — पूरा मैदान
• Three.js बनाम Babylon.js — अगर आपने इसे web-3D libraries तक सीमित कर लिया है
• Web Games के लिए Godot बनाम Unity — libraries के बजाय पूरे engines
• 2026 में Web Games Tech Stack — WebGL, WebGPU, और Wasm
• Cinevva Engine — Three.js पर बना हमारा open-source engine

ये web 3D के दो भारी-भरकम नाम हैं, और इन दोनों के बीच चुनाव आखिरकार सोच पर आ टिकता है। Three.js एक हल्का रेंडरर है जिसे आप बढ़ाते हैं। Babylon.js एक पूरा engine है जिसमें टूल्स पहले से ही डिब्बे में मौजूद हैं। दोनों बढ़िया हैं, दोनों फ्री हैं, और 2026 में दोनों WebGPU करते हैं। यहां बताया गया है कि कैसे चुनें।

इसके बजाय 2D engine या पूरे game engine के लिए, web game engines की तुलना देखें।

तुरंत फैसला

लाइब्रेरी बनाम फ्रेमवर्क

Three.js एक छोटा core रखता है और बाकी आप और कम्युनिटी पर छोड़ देता है। आपको एक शानदार रेंडरर, सीन ग्राफ, और मटीरियल मिलते हैं, फिर जब आपको physics, पोस्ट-प्रोसेसिंग, या कंट्रोल चाहिए तो आप ऐड-ऑन की तरफ बढ़ते हैं। यह सबसे लोकप्रिय web-3D लाइब्रेरी है और इसका ecosystem सबसे बड़ा है, यानी ज़्यादा उदाहरण, ज़्यादा ट्यूटोरियल, और ज़्यादा हायरिंग पूल।

Babylon.js एक ज़्यादा भरा-पूरा engine है, जिसे Microsoft का सहारा है। यह physics, एक GUI सिस्टम, एनिमेशन, सीन डीबग करने के लिए एक बिल्ट-इन Inspector, कोड शेयर करने के लिए एक ऑनलाइन Playground, और शेडर को विज़ुअली बनाने के लिए एक Node Material Editor के साथ आता है। अगर आप चाहते हैं कि टूलिंग और ढांचा खुद जुटाने के बजाय दिया हुआ मिले, तो Babylon पहले ही दिन आपको ज़्यादा देता है।

2026 में WebGPU

दोनों अब WebGPU को लेकर गंभीर हैं। Babylon.js 8.0 (मार्च 2025) ने सभी core engine शेडर को GLSL और WGSL दोनों में भेजना शुरू किया, जिससे एक कई-मेगाबाइट कन्वर्ज़न लेयर हट गई और WebGPU को टारगेट करते समय engine का आकार लगभग आधा रह गया। Babylon.js 9.0 (मार्च 2026) ने क्लस्टर्ड लाइटिंग, compute शेडर के ज़रिए वॉल्यूमेट्रिक लाइटिंग, एक फ्रेम ग्राफ, और एरिया लाइट्स के साथ इसे और आगे बढ़ाया।

Three.js के पास अपना प्रोडक्शन-रेडी WebGPURenderer है जिसमें ऑटोमैटिक WebGL2 फॉलबैक है, और TSL आपको दोनों बैकएंड के लिए एक बार शेडर लिखने देता है। हाल के रिलीज़ इसे लगातार बेहतर बनाते रहते हैं।

कुल मिलाकर: WebGPU दोनों में ठोस है। Babylon compute-शेडर से चलने वाले फीचर्स पर ज़ोर देता है; Three.js अपने रेंडरर को हल्का और लचीला रखता है।

TypeScript, बंडल साइज, और Ecosystem

Babylon.js TypeScript-first है, लगभग पूरी तरह TS में लिखा गया है, जिसे बड़े कोडबेस के लिए कई टीमें पसंद करती हैं। Three.js JavaScript है जिसके अलग टाइप डेफिनिशन हैं जो अच्छे से काम करते हैं पर सच्चाई का असली स्रोत नहीं हैं।

आकार के मामले में, Three.js का core छोटा और ज़्यादा ट्री-शेकेबल है, इसलिए एक मिनिमल सीन कम कोड भेजती है। Babylon बड़ा है पर स्कोप्ड पैकेज के ज़रिए मॉड्यूलर है, और इसके WGSL-नेटिव रास्ते ने WebGPU का फासला कम कर दिया।

Ecosystem में कच्चे आकार और कम्युनिटी आउटपुट के दम पर Three.js आगे है। डिब्बे-में-टूलिंग के मामले में Babylon आगे है।

कब क्या चुनें

Three.js तब चुनें जब आप एक हल्का, लचीला रेंडरर चाहते हैं, सबसे बड़ा ecosystem चाहते हैं, और चीज़ों को अपने तरीके से बनाने की आज़ादी चाहते हैं। कस्टम web-3D काम के लिए यह डिफ़ॉल्ट है और सबसे ज़्यादा काम आने वाला स्किल है।

Babylon.js तब चुनें जब आप मजबूत बिल्ट-इन टूलिंग (Inspector, Playground, Node Material Editor) वाला पूरा engine चाहते हैं, TypeScript-first डेवलपमेंट चाहते हैं, और कॉर्पोरेट-समर्थित स्थिरता चाहते हैं, और आप बैटरी शामिल पाने के बदले थोड़ा बंडल साइज देने में खुश हैं।

दोनों ही बढ़िया विकल्प हैं। हमने Cinevva Engine के लिए Three.js चुना क्योंकि हम एक हल्की, web-first नींव चाहते थे जिसे हम खुद आकार दे सकें।

आम सवाल

Three.js बेहतर है या Babylon.js?

दोनों बढ़िया और फ्री हैं। Three.js सबसे बड़े ecosystem वाला एक मिनिमल रेंडरर है, जो तब सबसे अच्छा है जब आप लचीलापन चाहते हैं और अपना ढांचा खुद बनाना चाहते हैं। Babylon.js एक ज़्यादा भरा-पूरा engine है जिसमें बिल्ट-इन physics, GUI, एक Inspector, और एक Playground है, जो तब सबसे अच्छा है जब आप टूलिंग दी हुई चाहते हैं और TypeScript-first डेवलपमेंट चाहते हैं। यह सोच का चुनाव है, क्वालिटी का फासला नहीं।

क्या Three.js और Babylon.js WebGPU सपोर्ट करते हैं?

हां, 2026 में दोनों WebGPU सपोर्ट करते हैं। Three.js के पास WebGL2 फॉलबैक और क्रॉस-टारगेट शेडर के लिए TSL के साथ एक प्रोडक्शन-रेडी WebGPURenderer है। Babylon.js 8.0 ने अपने core शेडर WGSL-नेटिव बनाए (WebGPU पर बंडल साइज घटाते हुए), और 9.0 ने वॉल्यूमेट्रिक लाइटिंग जैसे compute-शेडर फीचर जोड़े। बेसलाइन के तौर पर WebGL2 भेजें और जहां WebGPU उपलब्ध हो वहां उसका इस्तेमाल करें।

क्या Babylon.js एक game engine है और Three.js नहीं?

मोटे तौर पर, हां। Babylon.js एक पूरा engine है: इसमें physics, एक GUI सिस्टम, एनिमेशन, एक Inspector, और एडिटर-स्टाइल टूलिंग शामिल है। Three.js 3D ड्रॉ करने पर केंद्रित एक रेंडरिंग लाइब्रेरी है, इसलिए आप physics, कंट्रोल, और game सिस्टम दूसरे पैकेज या अपने कोड के ज़रिए जोड़ते हैं। यही इन दोनों के बीच का असली फर्क है।

कौन छोटा है, Three.js या Babylon.js?

Three.js का core छोटा और ज़्यादा ट्री-शेकेबल है, इसलिए एक मिनिमल सीन कम JavaScript भेजती है। Babylon.js कुल मिलाकर बड़ा है पर स्कोप्ड पैकेज के ज़रिए मॉड्यूलर है, और 8.0 में इसके WGSL-नेटिव शेडर ने WebGPU को टारगेट करते समय इसका आकार लगभग आधा कर दिया। सबसे कसे हुए बंडल के लिए, Three.js अभी भी जीतता है।

संबंधित

• PlayCanvas vs Three.js — तुलना में एक विज़ुअल एडिटर जोड़ें
• 2026 के लिए सबसे अच्छे Web Game Engines (तुलना) — पूरा मैदान
• 2026 में Web Games टेक स्टैक — WebGL, WebGPU, और Wasm
• Browser में Three.js + USDC — Three.js में USD 3D असेट लोड करना
• Cinevva Engine — Three.js पर बना हमारा ओपन-सोर्स engine

कोई भी game खोलकर यह नहीं सोचता कि "मैं signed distance field पर Hermite interpolation के साथ एक smooth falloff function लगाना चाहता हूँ।" वे सोचते हैं "मुझे एक गुफा खोदनी है" या "मुझे एक पहाड़ बनाना है" या "मुझे एक नदी बनानी है।"

terrain sculpting का तकनीकी पक्ष (marching cubes, SDF brushes, transvoxel seams) हमारी साथी research guide में बताया गया है। यह guide समस्या के दूसरे आधे हिस्से के बारे में है: sculpting की ताकत casual खिलाड़ियों के हाथ में कैसे दें और उसे एक 3D modeling tool की तरह नहीं, बल्कि खेल जैसा कैसे महसूस कराएँ।

Metaphor की समस्या

हर ऐसे game ने जो खिलाड़ियों को terrain दोबारा गढ़ने देता है, यही design समस्या हल की है: कच्चे sculpting parameters (radius, strength, falloff, operation type) ज़्यादातर खिलाड़ियों के लिए बेमतलब हैं। समाधान हमेशा एक ही रहता है: brush को किसी ऐसे metaphor में लपेटो जिसे खिलाड़ी पहले से समझता है।

Minecraft: Block एक सार्वभौमिक Metaphor के रूप में

Minecraft की खूबी यह है कि terrain editing सिर्फ़ inventory management है। आप एक block तोड़ते हैं। आपको एक block मिलता है। आप एक block रखते हैं। "brush" एक अकेला voxel है, "falloff" binary है (असर हुआ या नहीं), और "operation" है जोड़ना या हटाना।

TNT इसे और बड़ा कर देता है। आप इसे gunpowder और sand से बनाते हैं (वही चीज़ें जो आप खेलते हुए पहले ही जमा कर चुके हैं), इसे किसी भी दूसरे block की तरह रखते हैं, flint and steel से जलाते हैं, और यह terrain में से एक गोला काट देता है। blast radius 4-7 blocks होता है। blast resistance material के हिसाब से बदलती है: dirt और sand बिखर जाते हैं, stone आंशिक रूप से बच जाता है, obsidian पर कोई असर नहीं होता। पानी block destruction को रोक देता है पर entity damage को नहीं।

खिलाड़ी कभी blast radius को एक parameter की तरह नहीं सोचता। वे सोचते हैं "TNT ताकतवर है, obsidian सख्त है, पानी एक ढाल है।" terrain editing system पूरी तरह उन materials और items के ज़रिए व्यक्त होता है जिन्हें खिलाड़ी पहले से जानता है।

Valheim: किसान का Toolkit

Valheim एक अलग तरीका अपनाता है। blocks के बजाय यह खिलाड़ियों को pre-industrial खेती के औज़ार देता है:

Hoe (5 wood + 2 stone, पहले 10 मिनट में मिल जाता है) के चार modes हैं: Level Ground (आपकी खड़े होने की ऊँचाई तक समतल करता है), Raise Ground (मिट्टी जोड़ता है, हर इस्तेमाल पर 2 stone लगता है), Path (घास हटाता है), और Pave (cobblestone बिछाता है)। leveling mechanic कमाल का है: आप वहाँ खड़े होते हैं जहाँ आप ज़मीन चाहते हैं, और hoe आपके चारों ओर सब कुछ उसी ऊँचाई पर ले आता है। कोई numeric input नहीं। आपके पैर ही reference हैं।

Cultivator (5 bronze + 5 core wood, smelting की ज़रूरत) रोपाई करता है: मिट्टी जोतना, बीज बोना, घास उगाना, और वनस्पति फिर से उगाना। यह terrain को आकार नहीं देता पर उसे सजाता है। hoe से किसी ढलान को समतल करने के बाद, आप उसे cultivate करते हैं और एक जंगल लगाते हैं। terrain एक कहानी कहता है: कोई यहाँ था, उसने इस ज़मीन पर मेहनत की।

Pickaxe विनाश वाला पक्ष संभालता है। यह terrain में खोदता है, hoe के raise का उल्टा। तीनों औज़ार मिलकर (pickaxe खोदता है, hoe उठाता/समतल करता है, cultivator रोपता है) एक पूरी शब्दावली बनाते हैं जो असल दुनिया की खेती की क्रियाओं से मेल खाती है।

cost model मायने रखता है। ज़मीन उठाने पर stone लगता है। आप हर edit का बोझ महसूस करते हैं। आप किसी पहाड़ को मुफ़्त में terraform नहीं करते। resource cost sculpting को एक फ़ैसला बना देता है, checkbox नहीं।

Animal Crossing: कमाया हुआ Terraforming

Animal Crossing: New Horizons terraforming को एक 3-star island rating के पीछे रखता है। Tom Nook के Island Designer app देने से पहले आपको एक campsite बनाना होता है, villagers को बुलाना होता है, housing plots खड़े करने होते हैं, और कई दिनों तक अपने island को विकसित करना होता है (असल दुनिया के दिन, game-hours नहीं)। जब तक आप terraforming unlock करते हैं, तब तक आप island को समझ चुके होते हैं। आप जानते हैं नदियाँ कहाँ हैं, कौन-सी cliffs आपके पसंदीदा नज़ारों को रोकती हैं, और आप क्या बदलना चाहते हैं।

औज़ार खुद एक permit system इस्तेमाल करते हैं। Paths मुफ़्त हैं। Waterscaping (नदियाँ, तालाब, झरने बनाना) पर 6,000 Nook Miles लगते हैं। Cliff Construction पर और 6,000 लगते हैं। अतिरिक्त path types पर 2,000 प्रत्येक लगते हैं। आप अपनी creative toolkit बढ़ाने के लिए वही currency खर्च कर रहे हैं जो आपने gameplay से कमाई है।

editing tile-based है। एक बार में एक square। कोई radius slider नहीं। कोई strength parameter नहीं। आप cliff का एक tile ऊपर धकेलते हैं या नदी का एक tile खोदकर निकालते हैं। यह बंदिश इसे सरल बनाती है: सबसे बुरी गलती को सुधारने में एक button press लगता है। design योजना बनाने को बढ़ावा देता है (community ने Happy Island Designer बनाया, layouts की पहले से योजना बनाने वाला एक browser tool) और समय के साथ धीरे-धीरे सुधार करने को।

Cliffs 3 levels तक जा सकती हैं। नदियों को समुद्र से जुड़ना होता है। कुछ landmarks (airport, resident services) हिलाए नहीं जा सकते। ये बंदिशें सीमाएँ नहीं हैं। ये design हैं। ये उस "blank canvas paralysis" को रोकती हैं जो freeform editors में casual engagement को मार देती है।

No Man's Sky: Multi-Tool

No Man's Sky terrain manipulation को एक gun पर रखता है। Terrain Manipulator एक multi-tool upgrade है जिसके चार modes हैं: Mine (एक sphere में terrain हटाता है), Create (sphere या cube आकारों में terrain जोड़ता है), Restore (मूल generated state पर वापस ले जाता है), और Flatten (बड़े इलाकों को समतल करता है)।

metaphor एक sci-fi device है जो आपके हाथ में आ जाता है। आप दुनिया को edit करने के लिए निशाना लगाकर goli चलाते हैं। T और R keys sphere size को तीन presets के बीच बदलती हैं (small, medium, large)। कोई numeric radius नहीं। तीन sizes। बस यही पूरा UI है।

यह tool पहले mission में पेश किया जाता है। जब तक आप exploring शुरू करते हैं, तब तक आप पहले से जानते हैं कि गुफा कैसे काटें या landing pad कैसे समतल करें। create mode आपको terrain types चुनने देता है (rock, dirt, आदि), जो अंदर ही अंदर splat-map texture blending से मेल खाता है।

Energy drain sculpting को काबू में रखता है। Normal mode में यह उदार है। Survival mode में, हर edit काफ़ी मात्रा में resources खर्च करता है। दो difficulty levels पर एक ही tool casual sculptors और resource के प्रति सजग survivalists दोनों की सेवा करता है।

Astroneer: Vacuum Gun

Astroneer सबसे सरल संभव metaphor लेता है: मिट्टी के लिए एक vacuum cleaner। terrain पर निशाना लगाओ, trigger दबाए रखो, और यह मिट्टी खींच लेता है। खाली जगह पर निशाना लगाओ और यह मिट्टी वापस बाहर फेंक देता है। terrain आपके cursor के चारों ओर real time में बदलता है।

Augments इस व्यवहार को बदलते हैं: Alignment Mod surfaces को ग्रह की curve के सापेक्ष समतल बना देता है। Boost Mod गति बढ़ाता है। Wide Mod area of effect बढ़ाता है। Inhibitor Mod आपको terrain को बिल्कुल बदले बिना resources जमा करने देता है।

खूबी यह है कि terrain एक साथ एक resource भी है। जो मिट्टी आप vacuum करते हैं वह canisters भरती है। canisters की मिट्टी को Soil Centrifuge में materials में बदला जा सकता है। दुनिया को गढ़ना और resources जमा करना एक ही क्रिया है। आप इसलिए नहीं खोदते कि आपको गुफा चाहिए। आप इसलिए खोदते हैं कि आपको compound बनाने के लिए मिट्टी चाहिए। गुफा एक side effect है जो बाद में काम का बन जाता है।

Deep Rock Galactic: Mining एक टीम-वर्क के रूप में

Deep Rock Galactic terrain destruction को class roles से जोड़ता है। Driller के पास अपनी forearms पर लगे power drills होते हैं जो हर सेकंड 2m चौड़ा, 2.2m ऊँचा, 1m गहरा rock चबा जाते हैं। लगातार इस्तेमाल के बाद drills ज़्यादा गर्म हो जाते हैं (red होने में 5.5 सेकंड, 8 सेकंड cooldown) और सीमित fuel पर चलते हैं। हर dwarf के पास precision काम के लिए एक pickaxe होता है।

Driller का काम रास्ता बनाना है। ठोस rock में से point A से point B तक एक सुरंग काटना। टीम पीछे चलती है। terrain editing एक creative tool होने के बजाय mission objective की सेवा करता है (extraction pod तक पहुँचना)। पर side effect यह है कि टीम जिस भी cave system से खेलती है वह उनके फ़ैसलों से अनोखे ढंग से आकार लेता है। कोई दो runs एक जैसे नहीं दिखते।

co-op structure sculpting को सामाजिक बना देता है। Driller अकेले नहीं खोदता। Scout flares से गुफा को रोशन करता है। Engineer उन दीवारों पर platforms रखता है जिन्हें Driller ने उजागर किया। Gunner सुरंग के मुहाने की रक्षा करता है। terrain editing एक साझा वाक्य का एक verb है।

Teardown: विनाश एक पहेली के रूप में

Teardown terrain destruction को heist planning में लपेटता है। तैयारी के लिए आपके पास असीमित समय है: दीवारें तोड़ो, इमारतों के बीच से गाड़ियाँ चलाओ, explosives रखो, ramps बनाओ। फिर alarm बजता है और हर objective पर पहुँचकर भागने के लिए आपके पास 60 सेकंड होते हैं।

हर tool की एक भौतिक पहचान है। sledgehammer पास से चीज़ें तोड़ता है। blowtorch steel काटता है। Explosives दीवारें उड़ा देते हैं। fire extinguisher आग बुझाता है। गाड़ियाँ structures से टकराकर गुज़रती हैं। खिलाड़ी अमूर्त रूप में "terrain edit" नहीं करता। वे एक दीवार पर hammer घुमाते हैं और दीवार टूट जाती है।

physics इसे असली महसूस कराती है। support हटने पर structures ढह जाते हैं। आग फैलती है। धुआँ कमरों में भर जाता है। मलबा गिरता है। feedback loop तुरंत और भौतिक है: किसी चीज़ पर मारो, उसे टूटते देखो, नतीजों को एक के बाद एक होते देखो। casual खिलाड़ी इसे समझते हैं क्योंकि उन्होंने असल ज़िंदगी में hammer घुमाया है (या घुमाना चाहा है)।

Eco: नतीजे Game Design के रूप में

Eco वह दुर्लभ game है जहाँ terrain editing के स्थायी, साझा नतीजे होते हैं। बहुत ज़्यादा पेड़ काटो और हवा की quality गिर जाती है। बहुत आक्रामक तरीके से mine करो और आप water table को प्रदूषित कर देते हैं। हद से ज़्यादा शिकार करो और प्रजातियाँ विलुप्त हो जाती हैं। पूरा ecosystem simulate किया गया है।

खिलाड़ी कानून प्रस्तावित कर सकते हैं और उन पर वोट दे सकते हैं: "नदी के 200m के भीतर कोई logging नहीं" या "प्रति घन मीटर 10 gold का mining tax।" governance system terrain editing को एक राजनीतिक कृत्य बना देता है। आप जहाँ चाहें वहाँ बस खोद नहीं सकते। community आपको रोक सकती है।

यह gamification का चरम छोर है: sculpting system खुद ही core game loop बन जाता है। terrain वह साझा resource है जिस पर हर खिलाड़ी की क्रिया असर डालती है। sculpting एक creative tool नहीं है। यह game का केंद्रीय तनाव है।

Cinevva के लिए Design Patterns

ये games उन patterns की एक toolkit सुझाते हैं जिन्हें हम इस्तेमाल कर सकते हैं। सब एक साथ नहीं। परतों में, सबसे सुलभ से शुरू करते हुए और सबसे जटिल की ओर बढ़ते हुए।

Pattern 1: Object-Based Sculpting (TNT Pattern)

खिलाड़ियों को brush मत दो। उन्हें ऐसे objects दो जो इस्तेमाल होने पर terrain को दोबारा गढ़ देते हैं।

TNT / Dynamite: खिलाड़ी एक explosive बनाता या पाता है। उसे दुनिया में रखता है। fuse जलाता है (या फेंकता है)। terrain का एक गोला घट जाता है। radius explosive type पर निर्भर करता है। छोटा firecracker: 2m radius। मानक dynamite: 5m। Mega bomb (दुर्लभ drop): 15m। खिलाड़ी चीज़ें उड़ा रहा है, "terrain edit" नहीं कर रहा।

Pickaxe / Shovel / Drill: अलग-अलग खासियतों वाले handheld औज़ार। pickaxe rock को थोड़ा-थोड़ा काटता है (छोटा radius, तेज़, सख्त materials पर काम करता है)। shovel मिट्टी निकालता है (मध्यम radius, मुलायम ज़मीन पर तेज़, rock पर बेकार)। drill सुरंगें बनाता है (पतली और गहरी, चिकने बेलनाकार छेद छोड़ता है)। हर tool अंदर ही अंदर एक अलग SDF brush operation से मेल खाता है, पर खिलाड़ी उन्हें अलग feedback वाले अलग भौतिक objects के रूप में अनुभव करता है।

Bucket / Watering Can: terrain पर पानी डालो और यह ढलान से नीचे बहता है, एक channel घिसता हुआ। erosion brush अपने आप terrain gradient का पीछा करता है। खिलाड़ी brush का निशाना नहीं लगाता। वे पानी डालते हैं और नदी बनते देखते हैं। अंदर ही अंदर यह terrain slope से प्रभावित एक smooth-lower operation है।

Seeds / Saplings: उन्हें रोपो और terrain उगता है। समतल ज़मीन पर रखा गया एक seed packet समय के साथ (कई सेकंड में, एक animation के साथ) एक छोटी पहाड़ी में फूटता है। नंगे rock पर रखा गया एक tree sapling अपने आधार के चारों ओर मिट्टी का एक टीला बना देता है। "उगता" terrain बस एक nature skin वाला raise brush है।

Terraform Beacon: एक beacon रखो और यह समय के साथ अपने radius के भीतर हर चीज़ को धीरे-धीरे एक target height तक समतल कर देता है। building sites के लिए अच्छा। खिलाड़ी object रखता है और चला जाता है। flatten brush कम intensity पर अपने आप चलता है जब तक ज़मीन beacon height से मेल नहीं खा जाती।

Pattern 2: Tool Progression (Stardew Pattern)

खिलाड़ियों को कमज़ोर औज़ारों से शुरू कराओ जो छोटे edits करते हैं। gameplay के ज़रिए upgrade करो।

Tier 1 (मुफ़्त, तुरंत): खाली हाथ। छोटे उभार दबा सकते हैं (micro-smooth, 0.5m radius)। मुट्ठी भर मिट्टी उठा सकते हैं (micro-lower, 0.3m radius)। नगण्य असर। सिखाता है कि system मौजूद है।

Tier 2 (बुनियादी materials से बना): stone shovel, wooden pickaxe। छोटे edits के लिए इस्तेमाल लायक। एक campsite समतल करो। एक उथली खाई खोदो। 1-2m radius। यहीं ज़्यादातर casual खिलाड़ी रहते हैं।

Tier 3 (exploration या trading की ज़रूरत): Metal tools। बड़ा radius (3-5m)। नए operations unlock होते हैं: hoe से terrain उठाओ, chisel से चिकने मोड़ काटो।

Tier 4 (Endgame / दुर्लभ drops): Power tools, explosives, terraform devices। 10-20m radius। Cave boring। Mountain building। ये तमाशे वाले औज़ार हैं जो लंबे समय के खिलाड़ियों को इनाम देते हैं।

upgrade path एक tutorial के तौर पर भी काम करता है। हर tier एक नया concept पेश करता है। जब तक आप Tier 4 तक पहुँचते हैं, तब तक आपने एक tutorial screen से नहीं, बल्कि धीरे-धीरे संपर्क के ज़रिए terrain editing की शब्दावली आत्मसात कर ली होती है।

Pattern 3: Contextual Tools (Valheim Pattern)

tool को इस बात से मिलाओ कि खिलाड़ी क्या करने की कोशिश कर रहा है, इस बात से नहीं कि terrain को क्या चाहिए।

Building mode: जब खिलाड़ी building mode में होता है (दीवारें, फ़र्श, छतें रखते हुए), तो foundations के नीचे terrain अपने आप समतल हो जाता है। उन्हें एक अलग flatten tool की ज़रूरत नहीं होती। building system इसे संभालता है। Valheim की building ऐसे ही काम करती है: एक फ़र्श रखो, और ज़मीन समायोजित हो जाती है।

Farming mode: फ़सल बोते समय, cultivator मिट्टी जोतता है (surface material बदलता है) और छोटे उभार समतल करता है। खिलाड़ी खेती कर रहा है, terraforming नहीं। terrain editing कृषि क्रिया का एक side effect है।

Mining mode: जब terrain से resources काटे जाते हैं (ore veins, clay deposits, mineral nodes), तो extraction एक छेद छोड़ देता है। terrain editing resource gathering का एक side effect है। Astroneer यह बिल्कुल सही करता है: मिट्टी vacuum करो, resources पाओ, एक गुफा छोड़ दो।

Combat mode: हथियारों के धमाकों से craters बनते हैं। आग वनस्पति जला देती है। acid rock को घोल देता है। terrain damage combat का एक side effect है। Deep Rock Galactic के drills ऐसे ही काम करते हैं: वे एक साथ एक हथियार और एक terrain tool हैं।

Pattern 4: Social Sculpting (Eco Pattern)

एक साझा दुनिया में, हर edit एक सामाजिक कृत्य है। उसी के लिए design करो।

दिखने वाली authorship: जब कोई खिलाड़ी terrain गढ़ता है, तो इसका एक हल्का संकेत छोड़ो कि किसने किया। एक धीमी चमक। edited surface पर खिलाड़ी-रंग की एक tint। एक छोटा झंडा। दूसरे खिलाड़ी देख सकते हैं कि कोई यहाँ था और उसने landscape बदला।

सहयोगी projects: एक दावे वाले इलाके के भीतर terrain edits एक साझा लक्ष्य की ओर जमा होते हैं। "पहाड़ से झील तक एक नदी खोदो।" इलाके में सबको दिखने वाला progress bar। पूरा होने पर, नदी पानी से भर जाती है। sculpting एक साझा इनाम वाली समूह गतिविधि थी।

Approval zones: संरक्षित इलाकों में, terrain edits के लिए landowner की मंज़ूरी या आसपास के खिलाड़ियों के वोट की ज़रूरत होती है। यह sculpting को बंद किए बिना griefing रोकता है। edit को मंज़ूरी मिलने तक एक ghost के रूप में preview किया जाता है (पारदर्शी, outline वाला)।

सहमति से Undo: कोई भी खिलाड़ी एक terrain edit को वापस लेने का प्रस्ताव दे सकता है। अगर आसपास के पर्याप्त खिलाड़ी सहमत हों, तो edit कुछ सेकंड में मिट जाता है। No Man's Sky का restore mode, पर सामाजिक।

Pattern 5: प्राकृतिक शक्तियाँ (Erosion Pattern)

सीधी brush strokes के बजाय, खिलाड़ियों को प्राकृतिक प्रक्रियाएँ शुरू करने दो।

Rain summoner: एक पहाड़ी के ऊपर एक बादल रखो और बारिश होती है। बारिश समय के साथ पहाड़ी को घिसती है, channels काटती हुई और किनारों को मुलायम करती हुई। खिलाड़ी तय करता है कि बारिश कहाँ गिरेगी और कितनी देर चलेगी। erosion shader sculpting करता है।

Earthquake device: एक स्थानीय भूकंप शुरू करता है जो ज़मीन में दरार डालता है, fissures बनाता है, और प्रभावित इलाके में terrain को नीचे करता है। खिलाड़ी चुनता है कहाँ। physics simulation तय करती है कैसे।

Lava flow: एक बिंदु से lava छोड़ो और यह ढलान से नीचे बहता है, घाटियों को भरता हुआ और rock में कठोर होता हुआ। एक प्राकृतिक metaphor से बना नया terrain। अंदर ही अंदर यह एक rock material के साथ terrain gradient का पीछा करता हुआ raise brush है।

Wind sculptor: एक पंखा या फूँकने वाला device जो मुलायम terrain (sand, dirt) को हवा की दिशा में धकेलता है। समय के साथ, यह dunes और चिकनी ढलानें बनाता है। दिशात्मक झुकाव वाला smooth brush।

Freeze / Thaw: एक नदी में पानी जमाकर एक ice bridge बनाओ। एक जमी हुई पहाड़ी को पिघलाकर एक mudslide शुरू करो। एक terrain editing parameter के रूप में तापमान, weather items के ज़रिए व्यक्त।

Pattern 6: खोज और हैरानी (Infinite Craft Pattern)

प्रयोग को इनाम दो।

Combination effects: पानी के पास TNT एक hot spring बनाता है (crater + पानी का भराव + steam particles)। TNT craters में बोए गए बीज तेज़ी से बढ़ते हैं (crater में "उपजाऊ मिट्टी" होती है)। एक जमी हुई नदी जिसे dynamite किया जाए वह नीचे एक गुफा उजागर करती है।

छिपे हुए materials: काफ़ी गहरा खोदने पर अलग-अलग terrain परतें उजागर होती हैं: topsoil, clay, stone, crystal, lava। हर परत के गुण और रूप अलग हैं। जो खिलाड़ी ज़्यादा गहरा खोदते हैं वे ऐसी चीज़ें देखते हैं जो किसी और ने नहीं देखीं।

Fossils और artifacts: बेतरतीब terrain edits कभी-कभी दबी हुई चीज़ें खोद निकालते हैं: fossils, प्राचीन artifacts, treasure chests, दुर्लभ बीज। sculpting की क्रिया एक exploration mechanic बन जाती है। आप सिर्फ़ गुफा के लिए नहीं खोदते। आप इसलिए खोदते हैं कि आपको कुछ मिल सकता है।

Terrain memory: edited terrain याद रखता है कि उसके साथ क्या हुआ। TNT से उड़ाए गए इलाके में झुलसे निशान और जले किनारे होते हैं। बीजों से उगाए गए इलाके में गहरे रंग की मिट्टी होती है। बारिश से घिसे इलाके में चिकनी, पानी से घिसी textures होती हैं। terrain अपना इतिहास खुद बताता है।

Brush-से-Metaphor Mapping

खिलाड़ी जिस भी metaphor से जुड़ता है वह हमारी sculpting pipeline के एक तकनीकी brush operation से मेल खाता है। यह रहा अनुवाद-तालिका:

Pickaxe / Shovel छोटे radius, ऊँची strength, तेज़ falloff के साथ lower brush (heightmap या SDF से घटाना) से मेल खाता है। tool animation वही Chunk.applyBrush() call शुरू करती है।

TNT / Explosives बड़े radius, अधिकतम strength, sphere falloff के साथ lower brush से मेल खाते हैं। एक अकेला explosive event detonation point पर केंद्रित एक brush stroke लगाता है। हर material type की blast resistance brush पर एक strength multiplier से मेल खाती है।

Hoe / Flattener मध्यम radius, smooth falloff के साथ flatten brush से मेल खाता है। tool सक्रिय होने पर target height खिलाड़ी के पैर की स्थिति से लिया जाता है, बिल्कुल Valheim की तरह।

Seeds / Growth छोटे radius, smooth falloff के साथ raise brush से मेल खाता है, जो कई frames में लगाया जाता है (animated growth)। हर frame एक छोटा increment लगाता है। animation metaphor बेचता है जबकि brush geometry संभालता है।

Watering Can / Rain दिशात्मक झुकाव के साथ smooth brush से मेल खाता है। झुकाव ChunkManager.getNormal() से terrain slope gradient का पीछा करता है। brush center के नीचे के points उसके ऊपर के points से ज़्यादा नीचे होते हैं, जिससे प्राकृतिक erosion channels बनते हैं।

Terraform Beacon हर frame कम strength पर तब तक लगाए गए flatten brush से मेल खाता है जब तक convergence न हो जाए। beacon की world-space position target height तय करती है। radius beacon का area of effect है।

Drill एक sphere के बजाय एक ray दिशा के साथ projected किए गए lower brush से मेल खाता है। खिलाड़ी की aim दिशा से डाली गई ray हर depth step पर brush center तय करती है, जिससे एक बेलनाकार सुरंग बनती है।

Progression और Economy

खिलाड़ी क्या कमाते हैं

Tool unlocks: हाथों से शुरू करो। आम materials से बुनियादी औज़ार बनाओ। exploration, trading, या quest पूरा करने के ज़रिए उन्नत औज़ारों के recipes खोजो।

Capacity upgrades: बड़े explosives। चौड़े hoes। तेज़ drills। brush radius और strength tier के साथ बढ़ते हैं। अपने shovel को wood से iron में upgrade करने पर radius दोगुना हो जाता है।

Material types: जैसे-जैसे खिलाड़ी biomes explore करते हैं नए terrain materials unlock होते हैं। आप सिर्फ़ वही terrain types "create" कर सकते हैं जिनसे आपका सामना हुआ है। sand creation unlock करने के लिए एक रेगिस्तान देखो। basite unlock करने के लिए एक ज्वालामुखी देखो। No Man's Sky का create mode, exploration के पीछे रखा गया।

Recipes: Combination effects दिए नहीं जाते, खोजे जाते हैं। TNT crater में एक बीज बोओ और "Fertile Blast" खोजो। lava terrain पर पानी डालो और "Obsidian Formation" खोजो। हर खोज सूचीबद्ध की जाती है और साझा की जा सकती है।

इसकी कीमत क्या है

Resources: हर terrain edit materials खर्च करता है। terrain उठाने पर dirt/stone/sand लगता है (वह material जो रखा जा रहा है)। terrain नीचे करने पर materials मिलते हैं (जो आपके inventory में जाते हैं)। समतल करना दोबारा बाँटता है। resource प्रवाह economy को terrain system से जोड़े रखता है।

Energy / Durability: औज़ारों की durability या energy सीमाएँ होती हैं। pickaxe N इस्तेमाल के बाद टूट जाता है। terraform beacon fuel पर चलता है। यह अनंत editing रोकता है और प्राकृतिक session सीमाएँ बनाता है। खिलाड़ी फिर से आपूर्ति के लिए ब्रेक लेते हैं।

Time: कुछ operations तुरंत होते हैं (pickaxe swing)। दूसरे धीमे होते हैं (beacon flattening, seed growing, rain erosion)। धीमे operations धैर्य को इनाम देते हैं और spam को हतोत्साहित करते हैं। वे बेहतर भी दिखते हैं: एक बीज को पहाड़ी में फूटते देखना एक "raise" button दबाने से ज़्यादा संतोषजनक है।

दूसरे क्या देखते हैं

Edit footprint: हर terrain modification का एक visual signature होता है। TNT craters के गहरे, फटे किनारे होते हैं। Hoe से समतल किए इलाकों में एक चिकनी, जोती-हुई मिट्टी की texture होती है। उगाए गए terrain में गहरा, organic रंग होता है। बारिश से घिसे channels में watermarks होते हैं। खिलाड़ी landscape का इतिहास पढ़ सकते हैं।

Creator tags: edited terrain पर hover करके देखो कि किसने और कब बदला। "Sculpted by @PlayerName, 2 hours ago।" यह authorship का गर्व और सामाजिक जवाबदेही बनाता है।

Before/After: एक "time lapse" view जो terrain को उसके edit इतिहास के किसी भी बिंदु पर दिखाता है। landscape को बदलते देखने के लिए एक timeline slider scrub करो। यह संभव है क्योंकि तकनीकी guide के Phase 3 का CSG edit tree हर operation को क्रम में store करता है।

हम पहले क्या बनाते हैं

तकनीकी architecture का Phase 1 मौजूदा WebGL renderer पर heightmap sculpting के साथ काम करता है। जो casual tools हम उसके ऊपर ship कर सकते हैं:

1. Shovel (lower brush, छोटा radius)। सबसे बुनियादी tool। terrain पर click करो, एक छेद खोदो। dirt resources देता है।
2. Hoe (flatten brush, मध्यम radius)। जहाँ ज़मीन चाहिए वहाँ खड़े हो जाओ, hoe इस्तेमाल करो, terrain आपके पैरों के बराबर हो जाता है।
3. TNT (lower brush, बड़ा radius, one-shot)। materials से बनाओ, रखो, जलाओ, धमाका देखो। rubble देता है।
4. Seeds (raise brush, frames में animated)। समतल ज़मीन पर रोपो, terrain को एक छोटी पहाड़ी में उठते देखो, ऊपर वनस्पति आ जाती है।
5. Watering Can (slope bias के साथ smooth brush)। ढलानों पर डालकर उन्हें घिसो। प्राकृतिक दिखने वाले channels बनाता है।

पाँच औज़ार। पाँच अलग metaphors। एक underlying brush system। हर tool (radius, strength, falloff, operation, animation) का एक अलग configuration है जो एक item में लपेटा गया है जिसे खिलाड़ी मौजूदा PlacementTool जैसे ही interaction model के ज़रिए बनाता, equip करता और इस्तेमाल करता है।

हम चाहते हैं कि players वर्ल्ड को स्कल्प्ट करें। ग्रिड पर prefabs रखें ऐसा नहीं। ब्लॉक चालू-बंद करें ऐसा नहीं। असल में टेरेन को फिर से आकार दें: नदियां काटें, पहाड़ उठाएं, चट्टानों के किनारे smooth करें, गुफाएं खोदें। वैसी ही चीज़ जो ZBrush और Blender का sculpt mode आर्टिस्ट्स के लिए करते हैं, लेकिन एक मल्टीप्लेयर browser game के अंदर 60fps पर चलते हुए।

यह एक मुश्किल इंजीनियरिंग समस्या है जो डेटा रिप्रेज़ेंटेशन, mesh extraction, GPU compute, ब्रश के गणित और नेटवर्क सिंक्रोनाइज़ेशन तक फैली है। यह गाइड वह सब कुछ दर्ज करती है जो हमें मिला।

टेरेन रिप्रेज़ेंटेशन की दो दुनिया

हर स्कल्प्टिंग सिस्टम इस चुनाव से शुरू होता है कि टेरेन डेटा कैसे स्टोर किया जाए। यह चुनाव तय करता है कि किस तरह के edits मुमकिन हैं, वे कितनी तेज़ चलते हैं, और कितनी मेमोरी खर्च करते हैं।

हाइटमैप

एक हाइटमैप हर ग्रिड पॉइंट पर एक height value स्टोर करता है। आप इसे एक ग्रेस्केल इमेज की तरह सोच सकते हैं जहां brightness का मतलब elevation है। हमारा मौजूदा world/client टेरेन ठीक इसी तरह काम करता है: noise.ts FBM value noise के ज़रिए height बनाता है, और हर Chunk एक Float32Array हाइटमैप स्टोर करता है जो एक PlaneGeometry पर प्रोजेक्ट होता है।

हाइटमैप तेज़ होते हैं। सैंपलिंग bilinear interpolation के साथ एक ही array lookup है। LOD आसान है क्योंकि आप बस ग्रिड का रिज़ॉल्यूशन कम कर देते हैं। Splat-आधारित टेक्सचर ब्लेंडिंग सीधे UV ग्रिड पर मैप होती है। फिज़िक्स collisions एक height query तक सिमट जाती हैं।

सीमा topology है। एक हाइटमैप हर (x, z) coordinate पर सिर्फ एक height दर्शा सकता है। कोई गुफाएं नहीं। कोई overhangs नहीं। कोई arches नहीं। कोई tunnels नहीं। अगर कोई player एक ऐसी चट्टान स्कल्प्ट करे जो खुद पर मुड़ जाती है, तो हाइटमैप उसे स्टोर नहीं कर सकता। ऐसे टेरेन के लिए जो ज़्यादातर ढलवां पहाड़ियां और पहाड़ हैं, यह ठीक है। ऐसी freeform स्कल्प्टिंग के लिए जहां players ज़मीन के अंदर खोद सकें, यह एक dead end है।

वॉल्यूमेट्रिक (3D Scalar Fields)

विकल्प यह है कि 3D स्पेस के हर पॉइंट पर एक value स्टोर की जाए। अगर value ठोस मटेरियल के अंदर negative और बाहर positive है (या उल्टा), तो आपके पास एक Signed Distance Field (SDF) है। अगर value बस एक density है (किसी threshold से ऊपर ठोस, नीचे खाली), तो आपके पास एक density field है।

वॉल्यूमेट्रिक रिप्रेज़ेंटेशन किसी भी topology को संभाल लेते हैं। गुफाएं, overhangs, तैरते द्वीप, पहाड़ों के बीच से tunnels। इसका मोल मेमोरी और जटिलता है। 32-bit floats वाला एक 256^3 ग्रिड 64 MB खर्च करता है। एक 512^3 ग्रिड 512 MB खर्च करता है। और यह एक ही chunk के लिए है। इसे व्यावहारिक बनाने के लिए आपको sparse data structures (octrees, brick maps) चाहिए।

Mesh extraction का चरण भी आसान नहीं है। आप बस vertex Y positions सेट करके बात खत्म नहीं कर सकते। आपको एक ऐसा algorithm चाहिए जो scalar field को पढ़े और एक triangle mesh बनाए जो सतह का अनुमान लगाए वहां जहां field शून्य को पार करता है।

Mesh Extraction: Marching Cubes, Surface Nets, और Dual Contouring

Marching Cubes

Marching Cubes सबसे पुराना और सबसे ज़्यादा लागू किया गया isosurface extraction algorithm है। Lorensen और Cline द्वारा 1987 में प्रकाशित, यह voxel ग्रिड के हर cube की जांच करके काम करता है जहां हर corner की एक scalar value होती है। अगर कुछ corners सतह के अंदर (negative) और कुछ बाहर (positive) हों, तो उस cube के अंदर एक triangle mesh patch रखा जाता है।

हर cube के 8 corners होते हैं, हर एक या तो अंदर या बाहर, जिससे 256 संभावित कॉन्फ़िगरेशन (2^8) बनते हैं। ये symmetry के ज़रिए 15 अनोखे cases में सिमट जाते हैं। एक lookup table हर case को triangles के एक सेट से मैप करता है। Edge intersection points वहां linear interpolation से खोजे जाते हैं जहां edges पर sign बदलता है।

हाल की GPU implementations ने Marching Cubes को रियल टाइम स्कल्प्टिंग के लिए काफी तेज़ बना दिया है। UE5 पर 2025 की एक implementation हर GPU thread को एक cube देती है, हज़ारों को एक साथ process करते हुए। मुख्य बात यह है कि हर cube का triangulation उसके पड़ोसियों से स्वतंत्र है, जो इस algorithm को बेहद आसानी से parallel बना देता है।

MCHex (arxiv 2511.02064, 2025) Marching Cubes को adaptive hexahedral mesh generation तक बढ़ाता है, जिसमें positive Jacobian values की गारंटी होती है, जो सिमुलेशन meshes के लिए boundary approximation सुधारता है।

rupMC serial implementations से दर्जनों गुना तेज़ performance हासिल करता है और CPU/GPU heterogeneous architectures का इस्तेमाल करके parallel DMC variants से 4x तेज़ है।

मुख्य सीमा: Marching Cubes तीखे फ़ीचर्स के साथ संघर्ष करता है। एक 90-डिग्री edge गोल होकर एक smooth curve बन जाता है। टेरेन स्कल्प्टिंग के लिए यह आम तौर पर ठीक रहता है (प्राकृतिक टेरेन ज़्यादातर smooth होता है), लेकिन आर्किटेक्चरल फ़ीचर्स के लिए यह एक समस्या है।

Surface Nets

Surface Nets algorithms का एक नया परिवार है जो discrete scalar fields से ज़्यादा smooth meshes बनाता है। cube edges पर vertices रखने (Marching Cubes की तरह) के बजाय, Surface Nets हर उस cube में एक vertex रखता है जिसमें सतह होती है, फिर quads बनाने के लिए आसपास के vertices को जोड़ता है।

नतीजा स्वाभाविक रूप से ज़्यादा smooth होता है। एक 2024 paper (arxiv 2401.14906) ने एक हाई-परफ़ॉर्मेंस parallel Surface Nets implementation दिखाई जो sequential algorithms से एक से दो orders of magnitude तेज़ चलती है। fast-surface-nets Rust crate एक ही 2.5 GHz core पर छोटे lookup tables और SIMD acceleration का इस्तेमाल करके करीब 2 करोड़ triangles प्रति सेकंड बनाता है।

bevy-sculpter (v0.18.0, जनवरी 2026) अपनी मुख्य meshing strategy के तौर पर Surface Nets का इस्तेमाल करता है। यह crate चार ब्रश टाइप के साथ SDF-आधारित वॉल्यूमेट्रिक स्कल्प्टिंग देता है: hard CSG (तुरंत add/remove), smooth continuous (held input के लिए), blur (सतह smoothing), और flatten (target height पर सेट)। इसमें edits के बाद उचित signed distance field properties बहाल करने के लिए Fast Sweeping Method के ज़रिए SDF redistancing भी शामिल है।

Surface Nets, Marching Cubes (सरल, तेज़, लेकिन binary data पर aliased meshes बनाता है) और Dual Contouring (फ़ीचर-संरक्षित लेकिन जटिल) के बीच एक अच्छा बीच का रास्ता है।

Dual Contouring

Dual Contouring उन तीखे फ़ीचर्स को बनाए रखता है जो Marching Cubes और Surface Nets नहीं रख सकते। यह सिर्फ हर corner पर field के sign का नहीं, बल्कि edge intersections पर gradient (normal) का भी इस्तेमाल करके ऐसा करता है। एक QEF (Quadratic Error Function) minimization हर cell के अंदर vertex को उस position पर रखता है जो सभी edge intersection constraints को सबसे अच्छी तरह संतुष्ट करता है।

नतीजा: extracted mesh में तीखे edges और corners बने रहते हैं। perpendicular faces वाला एक cube एक cube ही रहता है।

इसका मोल जटिलता है। QEF solve में inter-cell dependencies होती हैं जो GPU parallelization को मुश्किल बनाती हैं। यह non-manifold meshes बना सकता है (वे edges जो दो से ज़्यादा polygons में शेयर होते हैं)। और implementation, Marching Cubes से ज़्यादा पेचीदा है, हालांकि Johannes Jendersie कहते हैं कि एक काम करने वाली Dual Contouring implementation करीब 200 लाइन कोड की है, जबकि एक मज़बूत Marching Cubes के लिए 500+ चाहिए।

Cubical Marching Squares (CMS) को एक बीच के रास्ते के तौर पर प्रस्तावित किया गया है: intercell-independent (GPU-अनुकूल) रहते हुए भी कुछ feature preservation देता है।

किसका इस्तेमाल करें

एक browser में player-सामने वाली टेरेन स्कल्प्टिंग के लिए:

Surface Nets सबसे मज़बूत उम्मीदवार है। यह binary data पर Marching Cubes के aliasing artifacts के बिना smooth meshes (प्राकृतिक दिखने वाला टेरेन) बनाता है। यह रियल टाइम re-meshing के लिए काफी तेज़ है। और इसे लागू करना Dual Contouring से आसान है।

Marching Cubes तब एक ठोस विकल्प बना रहता है जब GPU parallelism प्राथमिकता हो (हर cube स्वतंत्र है) या जब आपको सबसे ज़्यादा library support चाहिए। Reinder Nijhoff का WebGPU SDF Editor (जनवरी 2026) अपनी extraction pipeline में Marching Cubes और Surface Nets दोनों लागू करता है, जो पूरी तरह GPU पर चलता है।

Dual Contouring उन मामलों के लिए सबसे अच्छा रखा जाता है जहां performance से ज़्यादा आर्किटेक्चरल सटीकता मायने रखती हो। browser के संदर्भ में रियल टाइम टेरेन स्कल्प्टिंग के लिए आदर्श नहीं।

Transvoxel Algorithm: LOD Stitching का हल

जब voxel टेरेन को अलग-अलग रिज़ॉल्यूशन पर mesh किया जाता है (player के पास LOD0, दूर LOD2), तो boundaries पर दरारें बनती हैं। हाइटमैप के लिए यह एक सरल समस्या है: कम-रिज़ॉल्यूशन वाले पड़ोसी से मिलाने के लिए edge vertices को interpolate करें। हमारा मौजूदा chunk.ts ठीक यही stitchEdge() में करता है।

वॉल्यूमेट्रिक टेरेन के लिए, समस्या कहीं ज़्यादा कठिन है। LOD0 पर एक गुफा का मुंह boundary पर 30 triangles बना सकता है। वही region LOD1 पर पूरी तरह अलग topology के साथ 8 triangles बना सकता है। इनके बीच linear interpolation का कोई सरल तरीका नहीं है।

Eric Lengyel का Transvoxel Algorithm (2009) इसे "transition cells" से हल करता है। दो LOD levels के बीच की boundary पर, algorithm 9 हाई-रिज़ॉल्यूशन samples पर विचार करता है (8 cube corners के बजाय), जो 512 संभावित कॉन्फ़िगरेशन बनाते हैं जो 73 equivalence classes में आते हैं। हर class एक पूर्वनिर्धारित triangle pattern से मैप होता है जो दोनों रिज़ॉल्यूशन के बीच की खाली जगह को पूरी तरह भरता है।

यह algorithm स्थानीय voxel data पर काम करता है, इसलिए एक बदले हुए region को फिर से triangulate करना तेज़ है। यह रियल टाइम स्कल्प्टिंग के लिए ज़रूरी है: जब कोई player किसी LOD boundary के पास टेरेन edit करे, तो सिर्फ transition cells को फिर से बनाने की ज़रूरत होती है।

एक Rust implementation transvoxel crate के तौर पर मौजूद है। मूल lookup tables transvoxel.org पर उपलब्ध हैं।

ब्रश का गणित

एक स्कल्प्टिंग ब्रश एक function है जो किसी target point के आसपास एक radius के भीतर scalar field values को बदलता है। गणित सभी implementations में हैरानी की हद तक एक जैसा है, Blender से लेकर Unreal Engine से लेकर runtime game systems तक।

Falloff Functions

ब्रश का falloff तय करता है कि edit की strength केंद्र से किनारे तक कैसे घटती है। Blender 5.1 इन मानक profiles को परिभाषित करता है:

Smooth: f(d) = 3d^2 - 2d^3 (Hermite interpolation, हमारी noise.ts जैसा ही smoothstep)

Sphere: केंद्र पर तेज़, border के पास तीखा falloff। इसका अनुमान f(d) = sqrt(1 - d^2) के तौर पर लगाया जाता है।

Sharp: f(d) = (1 - d)^n जहां n > 2। एक बारीक point बनाता है।

Linear: f(d) = 1 - d जहां d केंद्र से normalized distance है (केंद्र पर 0, किनारे पर 1)।

Constant: f(d) = 1 जब d < 1, ब्रश की boundary पर hard cutoff।

Inverse Square: smooth और sphere के बीच hybrid, एक प्राकृतिक "मिट्टी जैसी" feel के लिए।

सभी मामलों में, d = distance_to_center / brush_radius, जिसे [0, 1] पर clamp किया जाता है। falloff value ब्रश की strength को गुणा करके हर पॉइंट पर असली field modification बनाती है।

Falloff Space

Blender sphere falloff (distance 3D world space में गणना की गई) और projected falloff (distance 2D screen space में गणना की गई) के बीच फ़र्क करता है। Projected falloff का मतलब है कि दो पॉइंट जो स्क्रीन पर पास दिखते हैं, एक-दूसरे को बराबर प्रभावित करते हैं, भले ही वे world space में बहुत अलग depth पर हों। टेरेन स्कल्प्टिंग के लिए, 3D world space falloff आम तौर पर ज़्यादा intuitive होता है।

मुख्य ब्रश ऑपरेशन

Raise/Lower (Displacement): ब्रश radius के भीतर scalar field में जोड़ें या घटाएं, falloff से weighted। हाइटमैप के लिए: height[i] += strength * falloff(d)। SDFs के लिए: sdf[i] -= strength * falloff(d) (घटाने से मटेरियल ज़्यादा ठोस होता है, सतह उठती है)।

Smooth (Laplacian): हर value को उसके पड़ोसियों के औसत से बदलें, falloff से weighted। यह detail मिटाता है और noise कम करता है। Laplacian filter एक छोटा kernel sample करता है (हाइटमैप के लिए 3x3, volumes के लिए 3x3x3) और mean की ओर ब्लेंड करता है। HC (Humphrey's Classes) smoothing एक variant है जो raw Laplacian से volume को बेहतर बनाए रखता है।

Flatten: field value को एक target height (या SDF space में distance) पर सेट करें, falloff से ब्लेंड करते हुए। target आम तौर पर stroke शुरू होने पर ब्रश के केंद्र पर sample किया जाता है, फिर स्थिर रखा जाता है। यह सपाट plateaus बनाता है।

Pinch/Inflate: vertices को surface normal की ओर या उससे दूर ले जाएं। SDF space में, यह gradient की दिशा में displace करने के बराबर है।

Grab: field के एक region को translate करें, जैसे आप मिट्टी खींच रहे हों। displacement vector, world space में प्रोजेक्ट किया गया mouse delta है, जो radius के भीतर field values पर लागू होता है।

Noise: ब्रश radius के भीतर field में procedural noise जोड़ें। smooth सतहों को खुरदरा करने के लिए उपयोगी।

Stamp: एक 2D ग्रेस्केल इमेज को displacement के तौर पर लागू करें, उसे cursor के नीचे की सतह पर प्रोजेक्ट करते हुए। Unreal Engine का Landscape tool टेरेन ब्रश के लिए इसका समर्थन करता है।

Adaptive Tessellation

sculpt-3D (React + Three.js browser sculpting) adaptive tessellation लागू करता है: जैसे-जैसे ब्रश mesh पर घूमता है, ब्रश के केंद्र के पास के triangles subdivide होते हैं ताकि deformation के लिए ज़्यादा vertices मिलें। यह "low-poly stretch" समस्या को रोकता है जहां एक मोटा mesh स्कल्प्टिंग से विकृत हो जाता है। subdivision एकसमान triangle quality के लिए symmetric splitting का इस्तेमाल करता है।

वॉल्यूमेट्रिक systems के लिए, adaptive tessellation की उसी तरह ज़रूरत नहीं होती क्योंकि mesh field से फिर से बनता है। इसके बजाय, आप उसी असर के लिए edits के पास स्थानीय रूप से voxel रिज़ॉल्यूशन बढ़ा सकते हैं (adaptive octrees)।

SDF स्कल्प्टिंग: Dreams का तरीका

Media Molecule का Dreams (PS4, 2020) अब तक शिप किया गया सबसे महत्वाकांक्षी इन-गेम स्कल्प्टिंग सिस्टम है। Alex Evans ने SIGGRAPH 2015 में इसका तकनीकी तरीका पेश किया।

रिप्रेज़ेंटेशन

Dreams ज्योमेट्री को 83^3 fp16 volume texture blocks में एक compound SDF function के तौर पर स्टोर करता है। हर sculpt 1 से 100,000 "edits" की एक सूची है, जहां हर edit एक प्रिमिटिव shape (sphere, cube, cylinder, cone, ellipsoid, torus, वगैरह) और एक blend mode के साथ एक CSG operation (add, subtract, color) है।

Blend modes soft-max और soft-min functions का इस्तेमाल करते हैं। एक "soft" blend प्रिमिटिव्स के बीच गोल transitions बनाता है (जैसे मिट्टी को एक साथ दबाया गया हो)। एक "hard" blend साफ़ boolean cuts बनाता है। blend radius user के नियंत्रण में होता है।

रेंडरिंग

Dreams एक triangle mesh extract नहीं करता। इसके बजाय, यह एक custom point-cloud renderer ("flecks") का इस्तेमाल करके सीधे SDF से render करता है। हर fleck surface normal के साथ एक छोटी disc है। सतहें खोजने के लिए SDF को sample किया जाता है, और उन पर flecks बांटे जाते हैं। यह mesh extraction की रुकावट को पूरी तरह टाल देता है लेकिन एक custom renderer की ज़रूरत होती है।

एक Three.js/WebGL वर्ल्ड के लिए, यह तरीका सीधे लागू नहीं होता। हमें meshes extract करनी होंगी। लेकिन CSG edit list वाली अवधारणा undo/redo और नेटवर्क सिंक्रोनाइज़ेशन के लिए बहुत प्रासंगिक है।

Mike Turitzin का Dynamic SDF Engine (2026)

Mike Turitzin द्वारा अभी विकसित हो रहा एक game engine dynamic SDFs को मुख्य रिप्रेज़ेंटेशन के तौर पर इस्तेमाल करता है। यह engine इनका समर्थन करता है:

गेमप्ले के दौरान विस्तृत बदलाव: smooth तरीके से या तीखे edges के साथ मटेरियल जोड़ना और हटाना। non-destructive बदलाव जैसे holes को हिलाना या अस्थायी tunnels बनाना जो player के पीछे गायब हो जाते हैं।

Brick maps और brick atlases sparse caching के लिए। पूरे SDF field को एक dense 3D ग्रिड में स्टोर करने के बजाय, field को "bricks" (छोटी 3D tiles) में बांटा जाता है। सिर्फ वे bricks आवंटित होते हैं जिनमें surface boundary होती है। यह ज़्यादातर खाली या ठोस स्पेस वाले दृश्यों के लिए मेमोरी को काफ़ी कम कर देता है।

Geometry clipmaps (Losasso & Hoppe, SIGGRAPH 2004) LOD के लिए। बढ़ते रिज़ॉल्यूशन पर nested regular grids camera की position को घेरते हैं। सबसे अंदरूनी ग्रिड का रिज़ॉल्यूशन सबसे बारीक होता है; बाहरी ग्रिड क्रमशः मोटे होते हैं। यह विशाल स्पेस का समर्थन करते हुए मेमोरी में भारी कमी देता है। Clipmaps जैसे-जैसे camera हिलता है incrementally अपडेट होते हैं, जो उन्हें streaming open worlds के लिए कारगर बनाता है।

Physics और collision सीधे SDF के विरुद्ध काम करते हैं। Sphere-tracing (step size के तौर पर SDF distance के साथ ray marching) कारगर raycasting देता है। Collision detection surface normal के तौर पर SDF gradient और penetration depth के तौर पर distance value का इस्तेमाल करता है।

Teardown: बड़े पैमाने पर Voxel Destruction

Teardown (Voxagon) इस spectrum का दूसरा छोर दर्शाता है: वर्ल्ड में हर ऑब्जेक्ट एक voxel volume है जिसे टुकड़े-टुकड़े नष्ट किया जा सकता है।

आर्किटेक्चर

Objects नियमित spacing पर voxel grids के तौर पर स्टोर होते हैं। engine रेंडरिंग के लिए Marching Cubes या SDFs का इस्तेमाल नहीं करता। इसके बजाय, यह fragment shaders में एक संशोधित DDA (Digital Differential Analyzer) algorithm का इस्तेमाल करके voxels को सीधे ray-trace करता है, जो OpenGL 3.3 पर बना है। Mipmaps एक dense octree structure बनाते हैं ताकि ray intersection के दौरान खाली स्पेस को पार करना तेज़ हो।

हर ऑब्जेक्ट के लिए, engine उसके oriented bounding box (OBB) को rasterize करता है और voxel intersections खोजने के लिए उसमें से एक ray trace करता है। सिर्फ OBB के backfaces render होते हैं, जिससे camera bounding volume में clip कर सकता है।

Destruction Synchronization (मल्टीप्लेयर)

Teardown का मार्च 2026 का मल्टीप्लेयर अपडेट एक semi-deterministic तरीका इस्तेमाल करता है। Structural destruction (holes काटना, ownership बदलना, joints फिर से जोड़ना) एक reliable network stream पर fixed-point integer math के ज़रिए संभाला जाता है। सभी clients वही deterministic commands चलाते हैं और वही world state पर पहुंचते हैं। Non-structural बदलाव (मलबा, particles) unreliable state synchronization इस्तेमाल करते हैं।

यह हमारे मल्टीप्लेयर वर्ल्ड के लिए एक ज़रूरी बात है: टेरेन edits deterministic होने चाहिए। अगर Player A एक पहाड़ स्कल्प्ट करे, तो सभी clients को वही field data से वही mesh बनाना होगा। edit commands (ब्रश position, radius, strength, operation type) authoritative data होने चाहिए, नतीजे वाला mesh नहीं।

ALICE-SDF: Compression और CSG Trees

ALICE-SDF (Adaptive Lightweight Implicit Compression Engine, v1.3.0 मार्च 2026) SDF-आधारित spatial data की एक Rust implementation देता है जो polygon meshes के मुकाबले 10-1000x compression करता है। यह इनका समर्थन करता है:

126 building blocks: 72 primitives, 24 operations, 7 transforms, और 23 modifiers। Smooth blending operations (union, subtraction, intersection), hard-edge bevels और stepped CSG transitions के लिए chamfer और stairs blends।

CSG tree diff/patch undo/redo और नेटवर्क सिंक्रोनाइज़ेशन के लिए। यह मल्टीप्लेयर स्कल्प्टिंग के लिए मुख्य फ़ीचर है: पूरी field state भेजने के बजाय, आप दो CSG trees के बीच का structural diff भेजते हैं। client नई state को फिर से बनाने के लिए patch लागू करता है। यह raw voxel data को delta-compress करने से कहीं ज़्यादा bandwidth-कारगर है।

CSG tree optimization जिसमें identity transform हटाना, nested transform merging, और modifier demotion शामिल है। यह जैसे-जैसे edits जमा होते हैं, tree को compact रखता है।

Mesh generation Marching Cubes और Dual Contouring दोनों के ज़रिए। Physics collision detection सीधे SDF के विरुद्ध काम करता है।

WebAssembly support browser integration को मुमकिन बनाता है। engine Rust में WASM bindings के साथ लिखा गया है, जो इसे एक Three.js application के लिए एक व्यावहारिक विकल्प बनाता है।

टेरेन के लिए WebGPU Compute

WebGPU अब 2025 के अंत तक सभी प्रमुख browsers में उपलब्ध है। Chrome 113+, Edge 113+, Firefox 141+, और Safari 26+ सभी इसे enabled के साथ शिप करते हैं। यह compute shader pipelines खोलता है जो पहले सिर्फ GPU-only थीं।

Performance

WebGPU compute shaders भारी parallelization के ज़रिए CPU methods से करीब 100x तेज़ टेरेन बनाते हैं। GPU एक साथ हज़ारों calculations चलाता है, और टेरेन generation लगभग पूरी तरह parallel है (हर vertex/voxel स्वतंत्र है)।

काम तीन tiers में संगठित होता है: Dispatch Level (GPU के पार workload बांटना), Workgroup Level (एक processing unit के भीतर shared memory), और Thread Level (अलग-अलग calculations)। WGSL (WebGPU Shading Language) shader language है।

रियल टाइम टेरेन स्कल्प्टिंग Pipeline

एक WebGPU स्कल्प्टिंग pipeline ऐसी दिखेगी:

1. ब्रश application (compute shader): ब्रश radius के भीतर scalar field values अपडेट करें। हर thread एक voxel संभालता है। एक uniform buffer से ब्रश parameters (position, radius, strength, falloff type, operation) पढ़ता है और modification लागू करता है।

2. Mesh extraction (compute shader): बदले हुए region पर Surface Nets या Marching Cubes चलाएं। Nijhoff का WebGPU SDF Editor इसे एक multi-stage pipeline के तौर पर लागू करता है: 16,384 cells के पार space partitioning, octree-आधारित cell splitting, फिर surface extraction।

3. Vertex buffer अपडेट (GPU-side): extracted vertices को CPU memory से होकर गए बिना सीधे एक render buffer में लिखें।

4. Normal computation (compute shader): mesh से या SDF gradient से vertex normals की गणना करें।

5. Render (मानक pipeline): mesh को मानक PBR materials के साथ draw करें।

चरण 1-4 सभी GPU पर बिना किसी data के JavaScript में लौटे चल सकते हैं। CPU को सिर्फ हर frame पर ब्रश parameters भेजने की ज़रूरत होती है।

WebGPU SDF Editor

Reinder Nijhoff का WebGPU SDF Editor (जनवरी 2026) Chrome में चलते हुए इस तरीके को दिखाता है। यह छह primitives (cone, cylinder, capsule, torus, box, sphere), configurable smooth blending के साथ तीन blend operations (union, subtraction, intersection), और hierarchical scene graphs का समर्थन करता है। हर primitive एक ही GPU buffer में 112 bytes लेता है।

रेंडरिंग pipeline ambient occlusion और temporal anti-aliasing के लिए 1,024 shadow maps का इस्तेमाल करता है। यह high-end GPUs पर interactive framerates पर चलता है।

हाइटमैप स्कल्प्टिंग: सरल रास्ता

अगर गुफा और overhang support ज़रूरी नहीं है, तो हाइटमैप स्कल्प्टिंग पूरी वॉल्यूमेट्रिक pipeline को टाल देती है। ज़्यादातर शिप किए गए games टेरेन editing को ऐसे ही संभालते हैं।

Runtime Implementation Pattern

Unity Runtime Terrain (JohannHotzel, जनवरी 2026) मानक pattern दिखाता है:

1. Raycast camera से mouse position के ज़रिए टेरेन hit point खोजने के लिए।
2. Hit point को मैप करें हाइटमैप coordinates पर।
3. ब्रश लागू करें आसपास के हाइटमैप values पर, falloff से weighted।
4. Mesh अपडेट करें बदले हुए हाइटमैप से vertex Y positions सेट करके।
5. Physics collider फिर से बनाएं नए mesh से मिलाने के लिए।

हमारे Three.js टेरेन के लिए, चरण 1-4 सीधे मौजूदा आर्किटेक्चर पर मैप होते हैं। Chunk class पहले से ही हाइटमैप स्टोर करती है और उनसे meshes बनाती है। स्कल्प्टिंग जोड़ने का मतलब होगा:

• chunk meshes के विरुद्ध एक raycasting सिस्टम (Three.js Raycaster)
• ब्रश application functions जो chunk.heightmap values बदलते हैं
• Mesh vertex अपडेट (Y positions सेट करें, normals फिर से calculate करें)
• प्रभावित region के लिए Splat map फिर से calculate करना (ताकि टेक्सचर ब्लेंडिंग नई slope/height दर्शाए)
• मौजूदा WebSocket protocol के ज़रिए दूसरे clients को edit का नेटवर्क broadcast (ब्रश position, radius, strength, operation)

Clipmap का तरीका

Landow.dev हाइटमैप टेरेन के लिए एक "wandering clipmap" बताता है: variable subdivision density वाला एक ही mesh जो player का पीछा करता है। हाइटमैप को अलग-अलग LOD levels वाली अलग meshes में chunk करने (जो हम अभी करते हैं) के बजाय, clipmap एक continuous mesh है जो camera के पास dense और किनारों पर मोटा है।

यह LOD stitching को पूरी तरह खत्म कर देता है। mesh में बस वहां ज़्यादा triangles होते हैं जहां आपको चाहिए और जहां नहीं चाहिए वहां कम। इसका मोल यह है कि स्कल्प्टिंग के लिए एक बड़े mesh को अपडेट करना पड़ता है, अलग chunks नहीं, जो बड़े edits के लिए महंगा हो सकता है।

Non-Destructive SDF हाइटमैप

Landow.dev एक तकनीक भी बताता है जहां हाइटमैप खुद एक SDF composition से बनता है। Shape instances (spheres, boxes, noise functions) एक compute shader में CSG operations का इस्तेमाल करके compose होते हैं, और output को एक हाइटमैप के तौर पर sample किया जाता है। यह हाइटमैप रेंडरिंग की सरलता बनाए रखते हुए non-destructive editing देता है (आप किसी भी समय किसी भी shape instance को हिला या मिटा सकते हैं)।

यह एक दमदार hybrid है: data रिप्रेज़ेंटेशन वॉल्यूमेट्रिक (SDF CSG tree) है, लेकिन रेंडरिंग का रास्ता एक मानक हाइटमैप mesh है। आपको SDF की तरफ़ से undo/redo और नेटवर्क-अनुकूल edit operations मिलते हैं, और हाइटमैप की तरफ़ से सरल रेंडरिंग और physics। सीमा बनी रहती है: कोई गुफाएं या overhangs नहीं।

बड़े वर्ल्ड के लिए Sparse Voxel Octrees

Dense 3D grids scale नहीं करते। हर तरफ़ 1 km वाला वर्ल्ड 0.5m रिज़ॉल्यूशन पर 8 अरब voxels मांगेगा। Sparse Voxel Octrees (SVOs) इसे space को बार-बार subdivide करके और सिर्फ़ उन octants के लिए storage आवंटित करके हल करते हैं जिनमें surface boundary होती है।

एक SVO स्वाभाविक रूप से hierarchical LOD देता है: किसी भी पॉइंट पर tree की गहराई effective रिज़ॉल्यूशन तय करती है। player के पास, tree पूरी तरह फैला होता है (अधिकतम detail)। दूर, यह एक मोटे level पर कटा होता है।

रेंडरिंग के लिए, SVOs को सीधे ray-trace किया जा सकता है (कोई mesh extraction की ज़रूरत नहीं)। एक GPU ray marcher हर tree level पर axis-aligned boxes के साथ rays को intersect करता है, खाली subtrees को पूरी तरह छोड़ते हुए। यह chunk-आधारित रेंडरिंग की overdraw समस्याओं को खत्म करता है और greedy meshing artifacts को टालता है।

AdamYuan का Vulkan-आधारित SVO builder काफ़ी performance दिखाता है: एक GTX 1660 Ti पर 2^10 रिज़ॉल्यूशन पर Crytek Sponza के लिए 19ms build time।

स्कल्प्टिंग के लिए, SVO modification कारगर है: सिर्फ़ ब्रश radius के भीतर leaf nodes अपडेट करने की ज़रूरत होती है, और tree structure अलग-अलग रिज़ॉल्यूशन को स्वाभाविक रूप से संभालता है। जहां player स्कल्प्ट करता है वहां detail जोड़ना (higher रिज़ॉल्यूशन पर nodes splitting) और जहां वे smooth करते हैं वहां detail हटाना (lower रिज़ॉल्यूशन पर nodes merging) data structure से अपने आप निकल आता है।

Browser deployment के लिए चुनौती यह है कि WebGL compute shaders का समर्थन नहीं करता, और जबकि WebGPU करता है, SVO construction और traversal algorithms को WGSL में लागू करना जटिल है।

मल्टीप्लेयर स्कल्प्टिंग के लिए नेटवर्क सिंक्रोनाइज़ेशन

हमारे वर्ल्ड में पहले से ही Cloudflare Durable Objects (world-chunk-do.ts) के ज़रिए मल्टीप्लेयर है। स्कल्प्टिंग जोड़ने का मतलब है सभी जुड़े clients के पार टेरेन modifications को सिंक्रोनाइज़ करना।

Delta Compression

Raw voxel data भेजना महंगा है। Oulu University के 2024 के एक अध्ययन ने delta-encoding को DEFLATE compression के साथ मिलाकर 2-8x payload सुधार हासिल किया, voxel updates को प्रति voxel एक byte से कम में पैक करते हुए। SDEC codec bit-packed delta encoding दिखाता है जो generic serialization के 1114 bytes के मुकाबले 259-byte औसत packets बनाता है।

Operation-आधारित Sync (सुझावित)

Field state सिंक्रोनाइज़ करने के बजाय, operations सिंक्रोनाइज़ करें। हर स्कल्प्टिंग action एक message बन जाता है:

interface TerrainEditMsg {
  t: MsgType.TerrainEdit
  brush: {
    position: [number, number, number]
    radius: number
    strength: number
    falloff: 'smooth' | 'linear' | 'sharp' | 'constant'
    operation: 'raise' | 'lower' | 'smooth' | 'flatten' | 'noise'
    targetHeight?: number
  }
}

server इसे सभी clients को broadcast करता है, और हर client अपने स्थानीय टेरेन data पर वही deterministic ब्रश operation लागू करता है। यह वही तरीका है जो Teardown structural destruction के लिए इस्तेमाल करता है: एक reliable stream पर deterministic commands।

ALICE-SDF का CSG tree diff/patch इसे और आगे ले जाता है: अलग-अलग ब्रश strokes के बजाय, diff पूरे CSG tree में structural बदलाव को दर्शाता है। यह नेटवर्क के पार कारगर undo/redo को मुमकिन बनाता है (inverse patch भेजें) और देर से जुड़ने वाले clients operation log को replay करके पूरी world state फिर से बना सकते हैं।

Priority और Throttling

जुड़े players के पास के टेरेन edits हाई-प्रायोरिटी होने चाहिए (तुरंत broadcast)। किसी भी player से दूर के edits को batch करके कम frequency पर भेजा जा सकता है। Enshrouded की voxel networking इस pattern का इस्तेमाल करती है: player के पास के टेरेन के लिए 60Hz updates, background regions के लिए 10Hz।

टेरेन update messages के लिए wire पर ZSTD compression packet sizes को 60% तक कम कर देता है।

Collaborative स्कल्प्टिंग: Concurrent Edits

जब कई players एक ही region को एक साथ स्कल्प्ट करें, तो आपको conflict resolution चाहिए। cSculpt (CNR Visual Computing Lab, 2016) ने इसे एक multiresolution merge algorithm से हल किया। हर edit को कई scales पर दर्शाया जाता है, और concurrent overlapping edits को उनके multiresolution representations को ब्लेंड करके merge किया जाता है।

हमारे मकसद के लिए, एक सरल तरीका काम करता है: server ordering के साथ last-write-wins। Durable Object हर edit को timestamp करता है और उन्हें क्रम में broadcast करता है। सभी clients edits को एक ही sequence में लागू करते हैं। चूंकि ब्रश strokes छोटे, स्थानीय, और additive/subtractive होते हैं, थोड़े पुनः-क्रमबद्ध concurrent edits का दृश्य नतीजा आम तौर पर "सही" क्रम से अलग नहीं दिखता।

INST-Sculpt: Neural SDF Editing (अनुसंधान का अग्रिम मोर्चा)

INST-Sculpt (arxiv 2502.02891, फ़रवरी 2025) neural SDFs के stroke-आधारित editing को मुमकिन बनाता है। Users सतह पर strokes बनाते हैं, और सिस्टम stroke के रास्ते के आसपास tubular neighborhoods के साथ अंतर्निहित neural field को deform करता है। Custom ब्रश profiles (configurable cross-sections) deformation के आकार को नियंत्रित करते हैं।

यह AI-जनित टेरेन के लिए दिलचस्प है: अगर base वर्ल्ड को एक neural SDF (एक छोटा neural network जो 3D coordinates को signed distance पर मैप करता है) के तौर पर दर्शाया जाए, तो स्कल्प्टिंग explicit voxel data के बजाय network weights बदलती है। रिप्रेज़ेंटेशन बेहद compact होता है (पूरे वर्ल्ड के लिए कुछ MB) लेकिन evaluation एक lookup table से ज़्यादा महंगा होता है।

यह अनुसंधान-चरण की तकनीक है। consumer hardware पर neural SDFs की inference लागत आज रियल टाइम game इस्तेमाल के लिए बहुत ज़्यादा है। लेकिन इस पर नज़र रखना सही है, खासकर जैसे-जैसे WebGPU shader क्षमताएं सुधरती हैं और model inference तेज़ होता है।

World Creator 2026.3: Commercial Terrain का अत्याधुनिक स्तर

World Creator (BiteTheBytes, मार्च 2026) टेरेन authoring tools के लिए commercial अत्याधुनिक स्तर दर्शाता है। Version 2026.3 ने automatic terrain adaptation (टेरेन रखे गए objects के अनुरूप ढलता है) के साथ GPU-आधारित टेरेन generation, LOD optimization के लिए camera-केंद्रित object distribution, और real-world elevation data import (GeoTIFF, HGT, DTED) जोड़ा।

उसके बाद से, World Creator 2026.4 (28 अप्रैल, 2026) ने numerical fields में mathematical expressions, hero objects को सतह में बैठाने के लिए terrain normal blending, पूरा decal support, और VRAM scaling जोड़ा जो उपलब्ध GPU memory के हिसाब से अधिकतम object count को समायोजित करता है। BiteTheBytes ने एक मुफ़्त Community Edition भी शिप किया जो feature-complete है लेकिन export-disabled है, असल में एक असीमित trial।

उनका तरीका सभी टेरेन operations के लिए GPU compute इस्तेमाल करता है: erosion simulation, river carving, texture painting। ब्रश tools रियल टाइम viewport feedback के साथ GPU-accelerated हैं। यह ऊपर बताई गई WebGPU compute pipeline से मेल खाता है, जो desktop GPUs पर चलती है।

हमने पहले ही क्या बनाया है: 24 Spikes और एक Production World

world/spikes/ directory में 24 self-contained prototypes हैं। ये खिलौना demos नहीं हैं। ये एक progressive R&D pipeline है जहां हर spike ने एक खास समस्या हल की, उसे एक target के विरुद्ध benchmark किया, और अगले को राह दिखाई। स्कल्प्टिंग सिस्टम इन सब पर बना है, सिर्फ़ बाद वाले वॉल्यूमेट्रिक पर नहीं।

Production Heightmap Terrain (world/client/)

लाइव वर्ल्ड Three.js WebGL में एक chunked हाइटमैप सिस्टम इस्तेमाल करता है:

• noise.ts FBM value noise (पहाड़ियों के लिए 5 octaves, ridges के लिए 4, micro-detail के लिए 3) के ज़रिए एक deterministic terrainHeight(wx, wz) function के साथ टेरेन height बनाता है
• chunk.ts Float32Array हाइटमैप से 3 LOD levels (32/8/4 segments प्रति 64-unit chunk) के साथ PlaneGeometry meshes बनाता है, और seeded random placement और per-object colliders के साथ instanced trees/billboards रखता है
• chunk-manager.ts player के आसपास rings में chunks stream करता है (LOD0 पर radius 1, LOD1 पर radius 3, LOD2 पर radius 6) जिसमें stitchEdge() में linear interpolation के ज़रिए edge stitching होती है, और physics layer के लिए getHeight(), getNormal(), और resolveCollisions() देता है
• terrain-material.ts slope और height-संचालित weights के साथ MeshStandardMaterial.onBeforeCompile के ज़रिए 4-layer splat-आधारित टेक्सचर ब्लेंडिंग (grass/rock/sand/dirt) करता है, साथ ही per-layer normal map blending
• character-controller.ts हर frame पर gravity, grounding, और slope rejection (अधिकतम slope cos 50 degrees) के लिए टेरेन height sample करता है। स्कल्प्टिंग को बदली हुई heights इस सिस्टम में तुरंत feed करनी होंगी वरना player edit किए गए टेरेन से होकर गिर जाएगा
• placement.ts में object placement tool के लिए chunk meshes पर hit करने वाला एक Raycaster पहले से है। ब्रश tool को raycasting को शून्य से बनाने के बजाय ठीक इसी pattern का पालन करना चाहिए
• protocol.ts world-chunk-do.ts Durable Object के ज़रिए मल्टीप्लेयर sync के लिए MessagePack-encoded messages परिभाषित करता है, जो अभी PlayerState, PlaceObject, RemoveObject, और Snapshot messages संभालता है। टेरेन edits के लिए एक नई message type चाहिए होगी
• world-chunk-do.ts (Cloudflare Worker) रखे गए objects को Durable Object storage में persist करता है और जुड़े players को 50ms अंतराल पर broadcast करता है। इसके पास अभी टेरेन modifications की कोई अवधारणा नहीं है

Spikes 01-11: Foundation Layer

इन spikes ने उन मुख्य systems को validate किया जिन पर स्कल्प्टिंग निर्भर होगी। इन्हें छोड़ने का मतलब है उन constraints को चूकना जिनका स्कल्प्टिंग सिस्टम को सम्मान करना होगा।

Spike 01 (Terrain + Instancing): Three.js में पहला टेरेन prototype। उस PlaneGeometry + हाइटमैप pattern और instanced object placement को स्थापित किया जो chunk.ts आज भी इस्तेमाल करता है।

Spike 02 (Rapier Physics Worker): एक ColliderDesc.heightfield() collider के साथ एक Web Worker में चलता Rapier 3D। autostep, slope limits, और snap-to-ground के साथ एक kinematic character controller बनाया। इस spike ने साबित किया कि physics एक heightfield के विरुद्ध main thread से अलग चल सकती है। अगर हम टेरेन स्कल्प्ट करें, तो physics heightfield को फिर से बनाना होगा या MC chunks के लिए एक trimesh collider से बदलना होगा।

Spike 05 (LLM Behaviors): सीधे टेरेन से जुड़ा नहीं, लेकिन game objects के लिए JSON behavior schema स्थापित किया। प्रासंगिक इसलिए कि स्कल्प्ट किए गए टेरेन फ़ीचर्स behaviors trigger कर सकते हैं (जैसे, एक कटी हुई नदी पानी के effects spawn करती है)।

Spike 06 (Chunk Streaming): player के हिलने पर dynamic loading के साथ पहला chunk load/swap सिस्टम। उस pattern को स्थापित किया जो chunk-manager.ts इस्तेमाल करता है: रंगीन regions जो load और unload होते हैं। chunks के unload और reload होने पर स्कल्प्टिंग को edit state बनाए रखनी होगी।

Spike 07 (GPU Vegetation from Density Maps): density maps के ज़रिए रखे गए instanced grass और trees जो टेरेन height और slope sample करते हैं। स्कल्प्टिंग vegetation placement को invalid कर देती है: अगर टेरेन height बदले, तो trees तैरते या दबे हुए हो सकते हैं। edit किए गए chunks के लिए density map को फिर से बनाना होगा।

Spike 08 (Terrain Material Shader Cost): triplanar projection, normal maps, और 4-layer blending को benchmark किया। हर फ़ीचर की सटीक ms लागत मापी। पाया कि triplanar + normals + 4 layers 45+ FPS पर budget के भीतर रहते हैं। यह budget स्कल्प्ट किए गए टेरेन के लिए मायने रखता है: अगर हम "edited soil" के लिए 5वीं layer जोड़ें या कटी हुई सतहों के लिए blending बदलें, तो हमें ठीक-ठीक पता है कितनी headroom मौजूद है।

Spike 09 (CSM Shadows Budget): 1024^2 रिज़ॉल्यूशन पर 3 cascades के साथ cascaded shadow maps। shadow लागत को ~1.5ms पर मापा। स्कल्प्ट किया गया टेरेन shadow maps बदलता है, लेकिन लागत टेरेन के आकार से बेपरवाह स्थिर रहती है।

Spike 10 (Geometry Clipmaps + Geomorphing): pop-in खत्म करने के लिए LOD levels के बीच geomorphing के साथ nested clipmap rings। स्थिर triangle count का मतलब है अनुमानित GPU लागत। Geomorphing स्कल्प्टिंग के लिए मायने रखता है: जब player किसी LOD boundary के पास स्कल्प्ट करे, तो LOD levels के बीच का morph edit दर्शाना चाहिए। अगर edit सिर्फ़ high-res ring में मौजूद है, तो geomorph target गलत है।

Spike 11 (Heightmap Chunk Streaming): ज़्यादा उन्नत chunk streaming जिसमें per LOD level loaded/loading/unloaded states दिखाता एक visual grid है। streaming budget स्थापित किया: प्रति frame अधिकतम chunks loaded, उन chunks की prioritization जिन्हें LOD upgrades चाहिए। स्कल्प्टिंग एक नया priority signal जोड़ती है: जिन chunks को player सक्रिय रूप से edit कर रहा है उन्हें कभी unload नहीं करना चाहिए।

Spikes 12-14: WebGPU + Three.js Integration

Spike 12 (WebGPU Marching Cubes): पहला वॉल्यूमेट्रिक spike। animated sphere caves के साथ चार 64^3 SDF chunks, जो पूरी तरह GPU पर चलते हैं। raw WebGPU इस्तेमाल करता है: SDF evaluation के लिए compute pipelines, Twinklebear case table (256 कॉन्फ़िगरेशन, हर एक में 16 entries) के साथ MC extraction, atomic vertex counter, और indirect draw। Performance target प्रति chunk <4ms, सभी 4 के लिए <12ms था। इसने validate किया कि GPU MC browser में रियल टाइम re-meshing के लिए काफी तेज़ है। हर बाद का वॉल्यूमेट्रिक spike यहां परिभाषित MC case table और WGSL shaders का फिर से इस्तेमाल करता है।

Spike 13 (Reset Baseline from Spike 12): Spike 12 के raw WebGPU draw path को Three.js के WebGPURenderer के अंदर चलने के लिए port किया, backend के device को सीधे access करते हुए। render pipeline अभी भी raw WebGPU इस्तेमाल करता है (drawIndirect struct Vertex vec4+vec4 के साथ)। इसने साबित किया कि custom compute और Three.js scene rendering एक ही GPU device पर साथ रह सकते हैं।

Spike 14 (Three.js WebGPU Incremental Hardening): raw render pipeline को positions और normals के लिए Three.js StorageBufferAttribute से बदला। MC compute सीधे इन GPU-resident buffers में लिखता है। drawIndirect buffer नियंत्रित करता है कि Three.js कितने vertices draw करता है। यह वह pattern है जो हर बाद का spike इस्तेमाल करता है: compute raw WebGPU रहता है, rendering Three.js scene graph से होकर जाती है। इन spikes में Three.js version 0.170.0 से 0.172.0 तक बढ़ा जैसे-जैसे WebGPU backend स्थिर हुआ।

Spike 15-17: Transvoxel LOD Stitching

Spike 15 (Transvoxel Seam Scaffold): तीन-zone आर्किटेक्चर जोड़ा: MC chunk (वॉल्यूमेट्रिक केंद्र), transition strip (MC boundary और हाइटमैप के बीच seam), और terrain ring (आसपास का हाइटमैप)। तीनों एक material pass शेयर करते हैं। इस चरण पर transition strip एक placeholder mesh है, असली Transvoxel cells नहीं।

Spike 16 (Transvoxel +X Face with Shared Heightmap): एक ही spike में दो ज़रूरी सफलताएं। पहली, SDF में सपाट टेरेन plane को एक shared Perlin हाइटमैप से बदला: एक 257x257 Float32Array जो GPU पर एक storage buffer के तौर पर upload हुआ, SDF compute shader में bilinear interpolation के ज़रिए sample किया गया। MC surface और हाइटमैप mesh अब एक ही ground truth पर सहमत हैं। दूसरी, GitHub से Eric Lengyel के reference data tables (transitionCellClass, transitionVertexData, transitionCellData) और npm transvoxel-data package fetch करके +X face के लिए असली Transvoxel transition cells लागू कीं। CPU 9-sample transition cells (512 कॉन्फ़िगरेशन, 73 equivalence classes) evaluate करता है, grid points पर SDF values को interpolate करके vertices रखता है, और mirrored cases के लिए winding inversion संभालता है।

Spike 17 (Dual MC 1x/2x LOD): अलग-अलग रिज़ॉल्यूशन पर साथ-साथ दो MC chunks। High-res: cell_scale=1.0 के साथ 62 cells। Low-res: cell_scale=2.0 के साथ 31 cells। MC shader को cell_scale और grid_points uniforms मिले। transition_shrink पेश किया: low-res chunk के face-0 boundary vertices को cell_scale के 15% अंदर खींचा जाता है, जिससे एक पतली खाली जगह बनती है जिसे Transvoxel transition cells z-fighting के बिना भरते हैं। यह वही LOD model है जो production सिस्टम को चाहिए: पास के chunks पूरी रिज़ॉल्यूशन पर, दूर के chunks आधी रिज़ॉल्यूशन पर, हर boundary पर Transvoxel।

Spikes 18-21: Transvoxel Corner Cases और GPU Acceleration

इन चारों spikes ने Transvoxel implementation में एक खास failure case हल किया। इन्हें एक साथ रखना अलग-अलग समस्याओं को छिपा देता है।

Spike 18 (Heightmap 2:1 Seam): Transvoxel को एक pure हाइटमैप boundary पर लागू किया जहां एक तरफ़ दूसरी से दोगुनी रिज़ॉल्यूशन है। कोई MC शामिल नहीं। एक 62-cell और 31-cell हाइटमैप chunk के बीच का seam Transvoxel transition tables से 15% low-face shrink के साथ बनता है। इसने validate किया कि Transvoxel सिर्फ़ MC ही नहीं, हाइटमैप-only case के लिए भी काम करता है।

Spike 19 (64/32/32/16 Corner Grid): सबसे कठिन stitching case: एक corner point पर मिलने वाले अलग-अलग रिज़ॉल्यूशन के चार chunks (64, 32, 32, और 16 cells)। seam सिस्टम को चार edges (A-B, A-C, B-D, C-D) के साथ हर दिशा के लिए सही winding के साथ transition cells बनानी होंगी। इस spike ने साबित किया कि Transvoxel tables custom-case logic के बिना multi-resolution corner संभालते हैं।

Spike 20 (GPU Transvoxel Corner): 64/32/32/16 corner layout के लिए Transvoxel transition cell generation को GPU पर ले गया। animated टेरेन के लिए हर frame transition cells फिर से बनाते समय CPU एक रुकावट थी। GPU compute MC extraction के उसी pass में seam vertices बनाता है।

Spike 21 (GPU MC + Transvoxel Corner): एक ही compute dispatch sequence में पूरी GPU MC extraction को GPU Transvoxel seam generation के साथ मिलाया। MC chunks और चारों seams दोनों GPU पर बनते हैं, vertex counts atomic counters के ज़रिए संभाले जाते हैं और drawIndirect के साथ draw होते हैं। यह seamless LOD transitions के साथ multi-resolution वॉल्यूमेट्रिक टेरेन के लिए पूरी GPU pipeline है।

Spikes 22-24: Hybrid Architecture

Spike 22 (Hybrid MC/Heightmap Policy): मुख्य architecture spike। Chunks डिफ़ॉल्ट रूप से हाइटमैप होते हैं। जब animated deformation sphere किसी chunk के AABB को intersect करता है, तो वह chunk MC mode में बदल जाता है। बाकी static हाइटमैप meshes रहते हैं। Layout: अलग-अलग रिज़ॉल्यूशन पर 64, 32/32, और 16-cell chunks। Transvoxel seams MC-to-heightmap transitions समेत हर boundary संभालते हैं। spike प्रति frame MC chunk count बनाम HM chunk count और vertex overflow track करता है।

Spike 23 (Policy-Driven Chunk Modes): Spike 22 के ऊपर एक patch के तौर पर load हुआ। camera-distance hysteresis जोड़ा (जब camera किसी threshold के पास हो तो chunks modes के बीच flicker नहीं करते) और एक edit mask (deform किए गए chunks MC mode में रहते हैं भले ही deformation source दूर चला जाए)। यह वह "sticky edit" behavior है जो स्कल्प्टिंग को चाहिए: एक बार player एक गुफा काट दे, तो वह chunk हमेशा वॉल्यूमेट्रिक रहता है।

Spike 24 (Policy + Clipmap Rings): सबसे उन्नत spike। Spike 23 के near-field policy सिस्टम को Spike 10 के far-field geometry clipmap rings के साथ मिलाता है। Three.js 0.183.1 पर upgrade किया गया। Near-field 64/32/16 रिज़ॉल्यूशन पर Transvoxel seams के साथ HM/MC hybrid इस्तेमाल करता है। Far-field static-center clipmap rings इस्तेमाल करता है जो camera का पीछा करते हैं। यह पूरी टेरेन रेंडरिंग आर्किटेक्चर है: जहां ज़रूरी हो वहां chunked वॉल्यूमेट्रिक स्कल्प्टिंग, बाकी हर जगह सस्ता clipmap टेरेन।

Marching Cubes क्यों, Surface Nets क्यों नहीं

इस गाइड का बाहरी अनुसंधान section browser टेरेन स्कल्प्टिंग के लिए Surface Nets को सबसे मज़बूत उम्मीदवार बताता है। लेकिन pipeline का हर spike Marching Cubes इस्तेमाल करता है। यह कोई संयोग नहीं है।

MC का परिभाषित फ़ायदा embarrassing parallelism है: हर cube पूरी तरह स्वतंत्र है। Spikes 12-24 के WGSL compute shaders शून्य inter-cell communication के साथ प्रति cube एक thread dispatch करते हैं। Atomic counters vertex allocation संभालते हैं। यह GPU workgroups पर पूरी तरह मैप होता है।

Surface Nets प्रति surface-वाले cell एक vertex रखता है, फिर पड़ोसियों को जोड़ता है। वह neighbor connectivity एक inter-cell dependency है। fast-surface-nets crate इसे CPU पर सावधान iteration order के साथ संभालता है। GPU पर, इसके लिए या तो दो-pass तरीका (vertices खोजें, फिर जोड़ें) या workgroups के भीतर shared memory चाहिए। दोनों WebGPU में मुमकिन हैं लेकिन जटिलता जोड़ते हैं।

व्यावहारिक सुझाव: स्कल्प्टिंग pipeline के लिए Marching Cubes के साथ ही रहें। यह हमारे codebase में सिद्ध है, WGSL shaders मौजूद और benchmarked हैं, और Transvoxel seam सिस्टम MC के edge-आधारित vertex placement के इर्द-गिर्द बना है। Surface Nets पर फिर से विचार करना तब सही है जब binary data पर MC का aliasing एक दिखने वाली समस्या बन जाए, लेकिन SDF टेरेन के लिए जहां values smooth gradients हैं, MC साफ़ नतीजे देता है।

स्कल्प्टिंग के लिए व्यावहारिक आर्किटेक्चर

spike sequence ने रेंडरिंग pipeline हल किया। जो बचा है वह है ब्रश सिस्टम, game systems के पार cascading side effects, और मल्टीप्लेयर सिंक्रोनाइज़ेशन। यहां योजना है, हर spike पर बनती हुई।

Phase 1: Heightmap स्कल्प्टिंग (न्यूनतम बदलाव, अधिकतम पहुंच)

production world/client/ कोड में chunk हाइटमैप बदलने वाले ब्रश tools जोड़ें। यह मौजूदा WebGL renderer के भीतर काम करता है और WebGPU की ज़रूरत नहीं है।

ब्रश input: placement.ts में PlacementTool pattern का पालन करें। इसके पास पहले से ही एक Raycaster है जो chunkManager.getChunkMeshes() पर hit करता है और hit point पर एक ghost mesh track करता है। एक TerrainBrushTool वही raycast करेगा लेकिन एक object रखने के बजाय chunk हाइटमैप बदलेगा। World.onMouseDown handler पहले से ही tool state के आधार पर dispatch करता है।

Chunk modification (Chunk.applyBrush): ब्रश world position को हाइटमैप grid coordinates पर मैप करें। ब्रश radius के भीतर हर grid point के लिए, falloff-weighted displacement की गणना करें और हाइटमैप value से जोड़ें/घटाएं। फिर mesh अपडेट करें: बदले हुए हाइटमैप से vertex Y positions सेट करें, central differencing के ज़रिए normals फिर से calculate करें (वही terrainHeight(wx +/- eps, wz) pattern जो chunk.ts line 155-158 में पहले से इस्तेमाल होता है), और प्रभावित region के लिए terrain-material.ts में createSplatMap() के ज़रिए splat map फिर से बनाएं ताकि slope-संचालित टेक्सचर ब्लेंडिंग अपडेट हो।

Character controller: CharacterController.update() grounding के लिए हर frame getHeight() call करता है। ChunkManager.getHeight() Chunk.sampleHeight() को delegate करता है, जो chunk के heightmap Float32Array से पढ़ता है। चूंकि हम उस array को सीधे बदल रहे हैं, character controller अगले frame पर शून्य अतिरिक्त wiring के साथ बदलाव उठा लेता है।

Object invalidation: chunk.ts में tree instances spawn के समय terrainHeight() sample करके रखे जाते हैं। स्कल्प्टिंग के बाद, प्रभावित इलाके के trees गलत height पर हो सकते हैं। Phase 1 इसे टाल सकता है (trees छोटे edits पर थोड़ा तैरते हैं)। Phase 2 को एक chunk.invalidateObjects() चाहिए जो heights फिर से sample करे और instance matrices फिर से बनाए। resolveCollisions() में इस्तेमाल होने वाले colliders के लिए भी यही।

Rapier physics (अगर integrated हो): Spike 02 ने साबित किया कि heightfield colliders काम करते हैं। अगर Rapier सक्रिय है, तो बदले हुए chunk के लिए heightfield collider को फिर से बनाना या patch करना होगा। Rapier का ColliderDesc.heightfield() एक flat Float32Array लेता है, इसलिए यह एक सीधा replacement है।

Network sync: protocol.ts में MsgType.TerrainEdit = 10 जोड़ें:

interface TerrainEditMsg {
  t: MsgType.TerrainEdit
  cx: number
  cz: number
  brush: {
    wx: number
    wz: number
    radius: number
    strength: number
    falloff: number
    operation: number
  }
}

WorldChunkDO इसे सभी clients को broadcast करता है और इसे Durable Object storage में रखे एक per-chunk edit log में append करता है। देर से जुड़ने वाले clients Snapshot message में edit log पाते हैं और टेरेन state फिर से बनाने के लिए इसे replay करते हैं। सभी clients वही deterministic ब्रश function लागू करते हैं, इसलिए वे वही हाइटमैप पर converge करते हैं।

Chunk unload/reload: Spike 06 और Spike 11 ने streaming pattern स्थापित किया। जब एक chunk unload और बाद में reload हो, तो उस chunk के edit log को base procedural हाइटमैप के विरुद्ध replay करना होगा। edit log server-side (Durable Object) स्टोर होता है और Snapshot message में शामिल होता है।

Phase 2: Spike 22-24 Architecture के साथ Volumetric स्कल्प्टिंग

Spike 24 pipeline को production world में port करें। जब कोई player सतह के नीचे स्कल्प्ट करे (एक गुफा काटना, एक tunnel खोदना), तो प्रभावित chunk हाइटमैप mode से MC mode में बदल जाता है।

WebGPU renderer migration: Spikes 13-14 ने साबित किया कि Three.js का WebGPURenderer scene graph के साथ custom compute host कर सकता है। production world MC chunks के लिए StorageBufferAttribute के साथ WebGLRenderer से WebGPURenderer पर जाता है। जब WebGPU उपलब्ध न हो तो Phase 1 हाइटमैप-only path पर fallback।

Per-chunk SDF allocation: Spike 22 के hybrid pattern का पालन करें। हर chunk एक हाइटमैप के तौर पर शुरू होता है। पहले वॉल्यूमेट्रिक ब्रश stroke पर, एक 64^3 Float32Array आवंटित करें, इसे हाइटमैप sample करके initialize करें (हर पॉइंट पर SDF value world.y - heightmap_value है), और MC rendering पर switch करें। Spike 23 का policy सिस्टम सुनिश्चित करता है कि chunk हमेशा के लिए MC mode में रहे (edit mask से "sticky edit" behavior)।

SDF shader में shared heightmap: Spike 16 का height_at() function। chunk के हाइटमैप को एक GPU storage buffer पर upload करें। SDF compute shader max(height_sdf, edit_sdf) evaluate करता है जहां height_sdf = world.y - height_at(world.xz) और edit_sdf में ब्रश modifications होते हैं। MC और हाइटमैप chunks अपनी boundaries पर ground truth पर सहमत होते हैं।

Transvoxel seams: Spikes 15-21 का पूरा stack। MC-to-heightmap boundaries shrink gap के साथ transition cells इस्तेमाल करती हैं। अलग-अलग रिज़ॉल्यूशन पर MC-to-MC boundaries Spike 17 का dual-LOD pattern इस्तेमाल करती हैं। Spike 19 का corner case 4-way intersections संभालता है। Spike 21 का GPU compute सारी seam geometry उसी dispatch में बनाता है।

Clipmap far-field: sculpting range के बाहर के टेरेन के लिए Spike 24 के clipmap rings। स्कल्प्टिंग इन rings को कभी नहीं छूती; वे base procedural हाइटमैप sample करते हैं।

Geomorphing: Spike 10 का geomorphing LOD transitions पर pop-in खत्म करता है। edit किए गए chunks के लिए, geomorph target में edit शामिल होना चाहिए। अगर एक chunk LOD0 पर MC है और उसका LOD1 पड़ोसी एक हाइटमैप है, तो geomorph दोनों representations के बीच ब्लेंड करता है। इसके लिए कम LODs पर भी edit log sample करना होता है।

Material budget: Spike 08 ने 4-layer triplanar + normals को 45+ FPS पर benchmark किया। MC chunks को वही material चाहिए। splat map को हाइटमैप slope के बजाय SDF gradient से बनाया जा सकता है (तीखा = rock, सपाट = grass)। यह 4-layer budget के भीतर रहता है।

Vegetation invalidation: Spike 07 का density-map vegetation टेरेन height और slope पर निर्भर करता है। जब एक chunk MC mode में बदले, तो tree instances को SDF surface sample करके फिर से बनाना होगा। overhangs पर या गुफाओं के अंदर के trees को cull करना होगा। chunk.ts के instanced mesh matrices नई surface से फिर से बनते हैं।

Phase 3: Undo/Redo और Network Sync के लिए CSG Edit Trees

raw SDF mutation को एक CSG operation tree से बदलें। हर ब्रश stroke एक operation (add, subtract, smooth blend) के साथ एक primitive (sphere, capsule, box) append करता है। SDF tree से फिर से calculate होता है।

फ़ायदे:

• Non-destructive: किसी भी edit को undo करने के लिए tree से हटाया जा सकता है
• Network-कारगर: raw field values नहीं, CSG operation broadcast करें
• Deterministic: सभी clients वही operation sequence से वही SDF बनाते हैं
• ALICE-SDF का CSG tree diff/patch नेटवर्क के पार bandwidth-कारगर सिंक्रोनाइज़ेशन और undo/redo देता है

Durable Object storage: प्रति chunk edit tree, Phase 1 के flat edit log की जगह लेता है। WorldChunkDO CSG tree structure स्टोर करता है, raw हाइटमैप deltas नहीं। Snapshot messages में tree शामिल होता है, और देर से जुड़ने वाले clients इसे evaluate करके स्थानीय SDF बनाते हैं।

Phase 4: Collaborative स्कल्प्टिंग

server-ordered operation replay के साथ concurrent edit support जोड़ें। Durable Object हर edit को timestamp करता है और क्रम में broadcast करता है। देर से जुड़ने वाले clients operation log पाते हैं और world state फिर से बनाते हैं। मौजूदा Snapshot message type प्रति chunk टेरेन edit history शामिल करने के लिए फैलती है।

चूंकि ब्रश strokes छोटे, स्थानीय, और additive/subtractive होते हैं, थोड़े पुनः-क्रमबद्ध concurrent edits का दृश्य नतीजा आम तौर पर "सही" क्रम से अलग नहीं दिखता। server ordering के साथ last-write-wins पर्याप्त है। Durable Object का tick() function (अभी player state के लिए 50ms अंतराल पर चलता है) उसी loop में टेरेन edit broadcasts जोड़ता है।

मुख्य संदर्भ

Algorithms:

• Lorensen & Cline, "Marching Cubes" (1987)
• Eric Lengyel, "Transvoxel Algorithm" (2009), transvoxel.org
• Losasso & Hoppe, "Geometry Clipmaps" (SIGGRAPH 2004)
• "A High-Performance SurfaceNets Discrete Isocontouring Algorithm" (arxiv 2401.14906, 2024)
• MCHex (arxiv 2511.02064, 2025)

Implementations:

• bevy-sculpter v0.18.0 (Rust, Surface Nets + SDF brushes)
• fast-surface-nets (Rust, 20M tri/sec)
• ALICE-SDF v1.3.0 (Rust + WASM, CSG tree diff/patch)
• WebGPU SDF Editor (Nijhoff, January 2026)
• SculptingPro (Unity runtime sculpting API)
• TerraBrush (Godot terrain sculpting GDExtension)

Games:

• Dreams (Media Molecule, SDF + point cloud rendering, SIGGRAPH 2015)
• Teardown (Voxagon, voxel DDA ray tracing, deterministic multiplayer destruction)
• Mike Turitzin's SDF engine (brick maps + geometry clipmaps, January 2026)

Network:

• "Optimizing payload size for voxel state synchronization" (Oulu, 2024)
• Teardown multiplayer (semi-deterministic destruction sync, March 2026)
• cSculpt (collaborative mesh sculpting with multiresolution merge)

आख़िरी अपडेट: जुलाई 2026।

10 सेकंड की क्लिप बनाना अब आसान है। हर बड़ा मॉडल यह कर लेता है। असली सवाल यह है: क्या आप 5 या 10 मिनट का ऐसा सुसंगत वीडियो बना सकते हैं जहाँ कोई किरदार पहले मिनट और आठवें मिनट में एक जैसा दिखे? जहाँ सैकड़ों frames के दौरान सीन एक साथ टिका रहे?

यही मुश्किल समस्या है। और यहीं चीज़ें तेज़ी से बदल रही हैं। यह गाइड हर उस मॉडल को कवर करती है जो हमें मिला है, चाहे वह native रूप से लंबा वीडियो बनाता हो या reference images के ज़रिए सुसंगत किरदारों के साथ long-form content बनाने के लिए ज़रूरी workflows को सपोर्ट करता हो। हमने इन्हें तीन tiers में बाँटा है: वे मॉडल जो सीधे मिनटों लंबा वीडियो बनाते हैं, वे मॉडल जिनमें मज़बूत reference image सपोर्ट है और जिन्हें आप continuation के ज़रिए extend करते हैं, और वे ओपन-सोर्स विकल्प जिन्हें आप खुद चला सकते हैं।

Tier 1: Native Long-Form जनरेशन (मिनट+)

ये मॉडल वीडियो को सेकंडों में नहीं बल्कि मिनटों में मापते हैं। ये जड़ से लंबी sequences में temporal consistency के लिए बनाए गए हैं।

LongCat Video

Meituan ने 2025 के आख़िर में LongCat Video रिलीज़ किया। यह 13.6 अरब पैरामीटर वाला diffusion transformer है और यह पहला ऐसा मॉडल है जो भरोसेमंद तरीके से 15 मिनट तक का सुसंगत वीडियो बना सकता है।

यह मॉडल एक ही unified pipeline में text-to-video, image-to-video, और video continuation को सपोर्ट करता है। I2V मोड में, input image वीडियो का literally पहला frame बन जाता है। यह कोई ढीला किरदार reference नहीं है जिसे आप किसी भी सीन में रख सकें। मॉडल उस शुरुआती frame से आगे की ओर animate करता है और साथ ही "Cross-Chunk Latent Stitching" का इस्तेमाल करके पूरे जनरेशन के दौरान मूल image को reference करता रहता है, जिससे color drift रुकता है और लंबी sequences में visual consistency बनी रहती है। एक अपडेटेड 2026 variant में audio-driven avatar जनरेशन जोड़ा गया है जिसमें 5+ मिनट के talking head वीडियो के लिए lip-sync है।

अंदरूनी तौर पर, LongCat बहुत बड़ी sequence lengths को संभालने के लिए Block Sparse Attention के साथ coarse-to-fine जनरेशन तरीका इस्तेमाल करता है। RLHF tuning से motion की क्वालिटी बेहतर होती है। VBench 2.0 benchmark पर यह कुल मिलाकर तीसरे स्थान पर है, Google Veo 3 और Shengshu के Vidu Q1 के पीछे।

उपलब्धता: MIT लाइसेंस के तहत ओपन सोर्स। fal.ai API के ज़रिए $0.04 प्रति जनरेटेड सेकंड पर उपलब्ध (720p पर 15 मिनट के वीडियो के लिए $36)। LongCat के अपने platform पर credit-आधारित pricing के साथ भी उपलब्ध।

Seaweed APT2

ByteDance का Seaweed APT2 एक अलग तरीका अपनाता है। पूरा वीडियो पहले से बनाने के बजाय, यह एक single H100 पर हर frame के लिए सिर्फ़ 0.16 सेकंड latency के साथ 24fps पर autoregressive तरीके से frames बनाता है। नतीजा 5 मिनट तक का स्थिर वीडियो है जिसकी temporal consistency टिकी रहती है।

तकनीकी जुगत है Autoregressive Adversarial Post-Training (AAPT), जो एक pretrained bidirectional video diffusion मॉडल को unidirectional autoregressive जनरेटर में बदल देती है। हर frame के लिए single network forward evaluation। यही चीज़ real-time जनरेशन को मुमकिन बनाती है।

कच्ची लंबाई के अलावा इस मॉडल को दिलचस्प बनाती है interactivity। आप camera को control कर सकते हैं, pose detection के ज़रिए किरदारों को animate कर सकते हैं, और वीडियो render होते समय सीन में फेरबदल कर सकते हैं। इसे "वीडियो बनाओ" से कम और "वीडियो को real time में steer करो" ज़्यादा समझिए।

उपलब्धता: सिर्फ़ research चरण। अभी सार्वजनिक रूप से उपलब्ध नहीं। 7B base मॉडल (Seaweed-7B) का एक paper प्रकाशित है पर APT2 weights रिलीज़ नहीं हुए हैं।

Helios

Helios Peking University से आता है, जो Wan 2.1 के ऊपर बना है। यह 14B पैरामीटर वाला मॉडल है जो एक single H100 पर 19.5 FPS पर मिनट-स्तर का वीडियो बनाता है। मुख्य खोज यह है कि यह long-video drifting को कैसे संभालता है। self-forcing या keyframe sampling जैसी पारंपरिक anti-drifting तकनीकों के बजाय, Helios training के दौरान drifting को simulate करता है ताकि मॉडल उसे सही करना सीख जाए।

यह native रूप से text-to-video, image-to-video, और video-to-video tasks को सपोर्ट करता है। I2V मोड जनरेशन को seed करने के लिए reference images स्वीकार करता है।

उपलब्धता: Apache 2.0 के तहत पूरी तरह ओपन सोर्स। मार्च 2026 में रिलीज़। Code और weights GitHub पर (PKU-YuanGroup/Helios)। Diffusers, SGLang, और vLLM-Omni में इंटीग्रेटेड। HuggingFace Spaces पर Gradio demo।

SkyReels V2 / V3

Skywork की SkyReels लाइन असीमित लंबाई के वीडियो को लक्ष्य बनाती है। V2 एक AutoRegressive Diffusion-Forcing आर्किटेक्चर इस्तेमाल करता है जो बिना किसी fixed duration cap के वीडियो बनाता है। जनवरी 2026 में रिलीज़ हुआ V3 एक ही मॉडल में reference image-to-video, video-to-video extension, और audio-guided avatar जनरेशन को एक साथ लाता है।

V3 1 से 4 reference images स्वीकार करता है और बने हुए वीडियो भर में subject की पहचान बनाए रखता है। video-to-video मोड cinematographic transitions के साथ सहज single-shot continuation और multi-shot switching को मुमकिन बनाता है।

Skywork ने 25 फरवरी 2026 को SkyReels V4 भेजा, जो 1080p/32fps तक एक ही dual-stream pass में वीडियो और audio को एक साथ बनाने वाला पहला ओपन-सोर्स मॉडल है। यह conditioning inputs के तौर पर text, images, video clips, masks, और audio स्वीकार करता है और जनरेशन, inpainting, तथा editing को एक framework में लाता है, V2/V3 की reference-and-extend लाइन को native ध्वनि के साथ आगे बढ़ाता है। अब यह Artificial Analysis text-to-video arena में शीर्ष के करीब है।

उपलब्धता: पूरी तरह ओपन सोर्स। 1.3B से 14B पैरामीटर के मॉडल। 540p और 720p पर उपलब्ध। Code और weights GitHub और HuggingFace पर।

Tier 2: मज़बूत Reference + Extension वाली छोटी क्लिप्स

ये मॉडल 8-60 सेकंड की क्लिप बनाते हैं पर मज़बूत reference image सपोर्ट और video extension features देते हैं। Long-form content के लिए, आप मॉडल के continuation या extension endpoints का इस्तेमाल करके क्लिप्स को आपस में जोड़ते हैं। Character consistency उन reference images से आती है जो जनरेशनों भर में टिकी रहती हैं।

यह वही व्यावहारिक workflow है जिसे ज़्यादातर creators आज एक मिनट से लंबे content के लिए इस्तेमाल करते हैं। प्रति-क्लिप क्वालिटी अक्सर native long-form मॉडलों से ज़्यादा होती है।

Kling 3.0 Omni (Kuaishou)

किसी भी वीडियो मॉडल में Kling का reference image सिस्टम सबसे पूरा है। यह reference inputs को तीन अलग श्रेणियों में बाँटता है, हर एक का अलग मकसद होता है:

Reference Images (image_urls): style और दिखावट के मार्गदर्शन के लिए 4 तक images। आप इन्हें अपने prompt में @Image1, @Image2 वगैरह के तौर पर tag करते हैं। ये पहला frame बने बिना समग्र लुक, सीन की style, और environment को प्रभावित करती हैं।

Elements (elements): समर्पित character/object inputs। हर element एक frontal_image_url (साफ़ सामने से ली गई फ़ोटो) के साथ-साथ वैकल्पिक reference_image_urls (अतिरिक्त angles) लेता है। आप इन्हें अपने prompt में @Element1, @Element2 के तौर पर reference करते हैं। मॉडल किरदार की पहचान निकालता है और उन्हें आपके बताए किसी भी सीन में रख देता है। adventure-movie-शैली के content के लिए यही मुख्य feature है: एक किरदार की फ़ोटो अपलोड करें, फिर बताएँ कि वे जंगल से गुज़र रहे हैं, ड्रैगन से लड़ रहे हैं, जो भी आप चाहें।

Start/End Frames (start_image_url, end_image_url): किसी खास image को पहले या आख़िरी frame के तौर पर pin करें। ये literal frames हैं, style guides नहीं।

तीनों श्रेणियों में कुल मिलाकर 7 तक reference inputs होते हैं (reference video भी इस्तेमाल करने पर यह घटकर 4 रह जाता है)। "@Element1 and @Element2 are having dinner at this table on @Image1" जैसा एक prompt किरदारों को सीन references के साथ जोड़ सकता है।

Long-form content के लिए, Kling दो रास्ते देता है। Multi-shot मोड एक ही call में 6 तक सीन बनाता है, हर एक का अपना prompt और duration (हर एक 3-15s)। Character elements सभी shots भर में अपने आप टिके रहते हैं। extend API वहीं से जारी रखता है जहाँ कोई पूरा हुआ वीडियो छूटा था, chained extensions के ज़रिए लगभग 3 मिनट तक पहुँचता है। V2V editing मोड मौजूदा वीडियो (3-10 सेकंड) लेता है और element references तथा एक text prompt का इस्तेमाल करके उसे बदलता है, source से camera motion और किरदार के staging को बनाए रखते हुए आपके references के आधार पर किरदारों और environments को restyle करता है। इससे Kling पहले से मौजूद footage को बेहतर बनाने के लिए खास तौर पर उपयोगी हो जाता है, low-fidelity 3D renders समेत।

Kling 3.0 Omni text-to-video, image-to-video, reference-to-video, और video editing को एक ही मॉडल में native audio जनरेशन और lip-sync के साथ लाता है। 17 जून 2026 को, Kuaishou ने Kling 3.0 Turbo जोड़ा, जो 720p और 1080p पर audio bundled के साथ एक तेज़ और सस्ता variant है (सूची मूल्य लगभग $0.11-0.14/sec), और Omni की editing pipeline को 4K वीडियो स्वीकार करने और output करने के लिए अपग्रेड किया।

उपलब्धता: Kuaishou, fal.ai ($0.084-0.112/sec), और Replicate के ज़रिए commercial API। klingai.com पर web interface।

Grok Imagine (xAI)

xAI ने 2026 की शुरुआत में Grok Imagine का Reference-to-Video मोड लॉन्च किया, जिसमें 1-7 reference images का सपोर्ट है। documentation साफ़ तौर पर इसे image-to-video से अलग बताती है: "image-to-video के उलट जहाँ source image शुरुआती frame बन जाता है, reference images यह प्रभावित करती हैं कि वीडियो में क्या दिखे, बिना पहले frame को lock किए।"

आप अपने prompt में images को <IMAGE_1>, <IMAGE_2> वगैरह के तौर पर tag करते हैं। "the model from <IMAGE_1> walks onto the runway wearing the shirt from <IMAGE_2>" जैसा prompt एक व्यक्ति reference को कपड़ों के reference के साथ जोड़ता है। मॉडल virtual try-on, product placement, और सीनों भर में character-consistent storytelling को संभालता है।

एक पाबंदी: आप एक ही request में reference images को image-to-video के साथ नहीं जोड़ सकते। या तो first-frame मोड या reference मोड, दोनों नहीं।

Grok Imagine में एक video extension endpoint भी है जो मौजूदा वीडियो के अंत में नई footage जोड़ता है। duration पैरामीटर सिर्फ़ नए हिस्से को control करता है। आप लंबा content बनाने के लिए extensions को chain कर सकते हैं।

xAI ने 3 जून 2026 को Grok Imagine 1.5 को API preview के तौर पर रिलीज़ किया, फिर 16 जून को इसे grok-imagine-video-1.5 के रूप में general availability में ले आया, और एक Fast variant consumer apps में क्रमशः आ रहा है। यह एक image-to-video मॉडल है जो एक single still को camera moves, माहौल, physics, और उसी inference pass में native रूप से बने synchronized audio के साथ cinematic motion में animate करता है। यह सुसंगत सीनों को chain करने के लिए multi-shot sequencing को सपोर्ट करता है, 6 सेकंड की 720p क्लिप लगभग 25 सेकंड में बनाता है, और फ़िलहाल Artificial Analysis image-to-video arena पर तीसरे स्थान पर है। Pricing 480p पर $0.08/sec और 720p पर $0.14/sec है, साथ में प्रति input image $0.01।

उपलब्धता: xAI API (जनवरी 2026 में लॉन्च), fal.ai, और Replicate। Python SDK, JavaScript/AI SDK, और REST API। audio के साथ 720p पर $0.05/sec। X Premium subscribers के लिए भी उपलब्ध।

Seedance 2.0 (ByteDance)

ByteDance का Seedance 2.0 किसी भी मॉडल से सबसे ज़्यादा reference inputs स्वीकार करता है: एक साथ 12 तक files, जिनमें 9 तक images, 3 videos, और 3 audio files शामिल हैं। मॉडल 8+ भाषाओं में phoneme-स्तरीय lip-sync के साथ native audio-video जनरेशन को सपोर्ट करता है।

हर एक image 30MB तक की हो सकती है। Reference videos 2-15 सेकंड के होने चाहिए। मॉडल किरदार की दिखावट, सीन की styling, और motion मार्गदर्शन के लिए references का इस्तेमाल करता है।

अगली छलांग पहले से तय है। ByteDance ने 23 जून 2026 को अपने Volcano Engine FORCE सम्मेलन में Seedance 2.5 की घोषणा की: एक ही pass में एक native 30-सेकंड क्लिप और 12 से बढ़कर 50 तक multimodal reference files। यह पहले Dreamina और Jimeng के ज़रिए क्रमशः आ रहा है, और API 16 जुलाई 2026 को BytePlus पर खुलेगा। अगर यह demo के मुताबिक़ आता है, तो यह इस गाइड में बताए गए clip-stitching का काफ़ी हिस्सा हटा देगा।

उपलब्धता: ByteDance official API (Volcengine के ज़रिए, फरवरी 2026 में लॉन्च) और third-party API providers। API के ज़रिए 480p-720p पर output, platform के ज़रिए 2K cinema resolution तक।

Runway Gen-4.5

Runway Gen-4.5 Artificial Analysis Text-to-Video leaderboard के शीर्ष पर 1,247 ELO के साथ लॉन्च हुआ, उस समय Veo 3 और Sora 2 Pro से आगे। 2026 के मध्य तक arena फिर से बदल चुका था (अब Gemini Omni Flash आगे है), पर Gen-4.5 cinematic क्वालिटी और controllable action के लिए एक top-tier मॉडल बना हुआ है। मॉडल text-to-video के लिए 2-10 सेकंड की क्लिप बनाता है और multi-shot sequencing के ज़रिए एक मिनट तक का character-consistent long-form वीडियो सपोर्ट करता है।

Image-to-video जनवरी 2026 में जोड़ा गया और यह सभी aspect ratios के लिए reference images सपोर्ट करता है। मॉडल diffusion आर्किटेक्चर के भीतर neural radiance fields और Gaussian splatting को एकीकृत करता है, जो इसे सिर्फ़ pixel-स्तरीय prediction के बजाय 3D ज्यामितीय समझ देता है। इसका मतलब बेहतर object permanence और भौतिक रूप से विश्वसनीय motion।

उपलब्धता: Commercial API और web interface। Node और Python के लिए SDKs। Replicate पर भी उपलब्ध।

Google Veo 3.1

Google का Veo 3.1 native रूप से 4, 6, या 8 सेकंड की क्लिप बनाता है। "Extend Video" feature (फ़िलहाल preview में) क्लिप्स को chain करके लगभग 1-2.5 मिनट तक पहुँचता है, हालाँकि लंबी sequences पर coherence drift कर सकती है।

"Ingredients to Video" feature input के तौर पर 3 तक reference images स्वीकार करता है। आप animate करने के लिए किरदार, backgrounds, और material textures दे सकते हैं। जब आप reference images इस्तेमाल करते हैं, तो मॉडल आपके visual references के ज़्यादा करीब रहता है और कम मनमाने बदलाव करता है। एक सीमा: reference image मोड सिर्फ़ 8-सेकंड duration विकल्प के साथ काम करता है।

जनवरी 2026 तक, Veo 3.1 ने reference-आधारित जनरेशन के लिए vertical video (9:16) और Vertex AI पर 4K upscaling जोड़ा।

उपलब्धता: Google Vertex AI API, Gemini API, और Google Flow। Google Cloud account ज़रूरी।

Google Gemini Omni Flash

Google ने मई 2026 में I/O में Gemini Omni family की घोषणा की और अपने पहले मॉडल के तौर पर Gemini Omni Flash भेजा। इसने जल्दी ही Artificial Analysis arena पर Veo 3.1 से आगे शीर्ष स्थान ले लिया। खास बात है conversational वीडियो: आप text, images, या video से एक 10-सेकंड क्लिप बनाते हैं, फिर उसे follow-up निर्देशों के ज़रिए संपादित करते हैं जो एक-दूसरे पर बनते जाते हैं। lighting बदलें, outfit बदलें, camera समायोजित करें, सब कुछ शून्य से दोबारा बनाए बिना।

reference सपोर्ट के लिए, Omni Flash images और छोटी video clips को style, motion, और effect references के तौर पर स्वीकार करता है, audio references की योजना है। Character consistency conversational edits भर में टिकी रहती है, हालाँकि Google के अपने docs बताते हैं कि scene changes और camera pans में यह फिसल सकती है, इसलिए किरदार-भारी output को भेजने से पहले जाँच लें।

उपलब्धता: API (gemini-omni-flash-preview) 30 जून 2026 को Google AI Studio और Gemini API के ज़रिए public preview में खुला, output के प्रति सेकंड लगभग $0.10 पर। हर क्लिप पर एक SynthID watermark होता है। Consumer access Gemini app, Google Flow, और YouTube Shorts के ज़रिए चलता है।

OpenAI Sora 2 / Sora 2 Pro

बंद हो रहा है (2026): OpenAI Sora को समेट रहा है। consumer Sora app 26 अप्रैल 2026 को बंद हो गया, और Sora 2 API 24 सितंबर 2026 को बंद हो जाएगा, बिना किसी घोषित उत्तराधिकारी के। नीचे दी गई क्षमताएँ अब भी उल्लेखनीय हैं, पर Sora पर कोई नई pipeline न बनाएँ। इसके बजाय Kling, Grok Imagine, या कोई open मॉडल इस्तेमाल करें।

Sora 2 Pro 20 सेकंड तक की क्लिप बनाता है। Characters API Kling या Grok से अलग तरीका इस्तेमाल करता है: static images अपलोड करने के बजाय, आप API को किसी वीडियो क्लिप की ओर इशारा करके (1-3 सेकंड timestamp range के साथ) एक character_id बनाते हैं। Sora चेहरे की बनावट, शरीर के अनुपात, कपड़ों की style, और दूसरी पहचानने वाली विशेषताएँ निकालने के लिए वीडियो frames का विश्लेषण करता है। वह character_id अनिश्चित काल तक टिका रहता है और असीमित भविष्य की जनरेशनों भर में दोबारा इस्तेमाल हो सकता है।

आप प्रति जनरेशन 2 तक अपलोड किए गए किरदारों को reference कर सकते हैं। मार्च 2026 तक, character references सिर्फ़ लोगों के लिए नहीं बल्कि objects और जानवरों के लिए भी काम करते हैं। Video extension continuation के context के तौर पर पूरी initial क्लिप का इस्तेमाल करता है।

किरदार बनाने के लिए character सिस्टम को वीडियो input (static images नहीं) चाहिए। अगर आपके पास सिर्फ़ फ़ोटो हैं, तो आपको पहले एक छोटा वीडियो बनाना होगा, फिर उससे किरदार निकालना होगा।

उपलब्धता: Production workflows के लिए Batch API सपोर्ट के साथ OpenAI API।

MiniMax Hailuo 02

Hailuo 02 लॉन्च के समय Artificial Analysis benchmark पर वैश्विक स्तर पर #2 रहा, Veo 3 को हराते हुए। यह native 1080p पर 10-सेकंड की क्लिप बनाता है और इसमें इस क्षेत्र की कुछ बेहतरीन physics simulation है। मॉडल gymnastics और acrobatics जैसी अत्यधिक motion को बिना टूटे संभालता है।

यह facial recognition और body tracking के ज़रिए मज़बूत character consistency के साथ image-to-video जनरेशन सपोर्ट करता है। Noise-aware Compute Redistribution आर्किटेक्चर सीन की जटिलता के आधार पर गतिशील रूप से compute आवंटित करता है।

MiniMax तब से Hailuo 02 से आगे Hailuo 2.3 family (Standard, Pro, Fast, Fast Pro) पर बढ़ चुका है, जो physical action, stylization, और किरदार के micro-expressions को बेहतर बनाता है। यह 6 सेकंड पर 1080p या 10 सेकंड पर 768p output करता है और MiniMax platform तथा fal.ai के ज़रिए उपलब्ध है।

उपलब्धता: Commercial API। MiniMax platform, fal.ai, और Replicate के ज़रिए उपलब्ध। $0.28 प्रति वीडियो।

Luma Ray3.2

Luma का Ray2 अब Ray3 family से आगे निकल चुका है। Ray3 (सितंबर 2025) ने पहचान lock के लिए Character Reference और एक Modify video-to-video मोड जोड़ा, और Ray3.2 (9 जून 2026) ने प्रति क्लिप 16 तक keyframes के साथ frame-स्तरीय control, एक Reframe feature, और 20 सेकंड तक की क्लिप्स जोड़ीं, साथ ही Ray3 लाइन का पहला public API। Output native 1080p है, Hi-Fi upscale के ज़रिए 4K उपलब्ध है। Image-to-video reference images को start या end keyframes के तौर पर स्वीकार करता है।

उपलब्धता: Luma API और web interface।

Pika 2.5

Pika Pikaframes के साथ एक keyframe-आधारित तरीका अपनाता है। 2-5 keyframes (अहम पलों पर reference images) अपलोड करें और मॉडल उनके बीच सहज transitions बनाता है। कुल duration 20-25 सेकंड तक पहुँचता है।

Pikascenes 10 तक reference images स्वीकार करता है और उन्हें एक ही वीडियो में जोड़ता है। मॉडल हर reference की भूमिका (character, background, prop) अपने आप पहचानने के लिए image recognition का इस्तेमाल करता है।

उपलब्धता: Pika web platform और API। Free से Pro तक subscription plans।

Tier 3: Self-Hosted Workflows के लिए ओपन-सोर्स मॉडल

ये मॉडल छोटी क्लिप बनाते हैं पर ये पूरी तरह ओपन हैं। आप इन्हें अपने hardware पर चला सकते हैं, इन्हें fine-tune कर सकते हैं, और API निर्भरताओं के बिना custom extension pipelines बना सकते हैं।

Wan 2.1 (Alibaba)

Wan 2.1 वह नींव है जिस पर कई दूसरे मॉडल बने हैं (Helios समेत)। Wan-VAE आर्किटेक्चर किसी भी लंबाई के 1080p वीडियो को encode और decode करता है और साथ ही temporal जानकारी बनाए रखता है। मॉडल 480p और 720p पर I2V variants में आता है, साथ ही एक First-Last-Frame-to-Video मॉडल जो दो reference images के बीच वीडियो बनाता है।

Wan-Edit खास संरचनाओं या किरदार poses को बनाए रखते हुए reference images का इस्तेमाल करके style और content transfer की इजाज़त देता है। Wan 2.2 (जुलाई 2025) नई open रिलीज़ है, एक Mixture-of-Experts मॉडल जिसका 5B variant एक single RTX 4090 पर चलता है, अब भी Apache 2.0 के तहत। self-host करने वालों के लिए एक अहम चेतावनी: Wan 2.5 पर closed हो गया। नए Wan 2.5, 2.6, और अब 2.7 (जो 2026 के मध्य की Artificial Analysis with-audio arena पर तीसरे स्थान पर है) ने synced audio और ऊँचा resolution जोड़ा पर ये API-only हैं, बिना public weights के, इसलिए 2.2 अब भी open की छत है। Wan 2.7 weights के downloadable होने का दावा करने वाले SEO pages को नज़रअंदाज़ करें। official GitHub org और Hugging Face account 2.2 पर ही रुकते हैं।

HunyuanVideo (Tencent)

Tencent का 13B पैरामीटर मॉडल 2025 के ज़्यादातर हिस्से में ओपन-सोर्स video जनरेशन में अग्रणी रहा। HunyuanVideo-I2V reference image जानकारी शामिल करने के लिए एक pre-trained MLLM के साथ token replace तकनीक का इस्तेमाल करता है। नवंबर 2025 में रिलीज़ हुए HunyuanVideo-1.5 ने दक्षता बेहतर की। HunyuanCustom multimodal-driven customized video जनरेशन को मुमकिन बनाता है।

LTX-2 (Lightricks)

Lightricks ने जनवरी 2026 में LTX-2 को पूरे weights, inference code, और training code के साथ open-source किया। यह एक DiT-आधारित मॉडल है जो वीडियो और synchronized audio को एक ही pass में एक साथ बनाता है, native 4K पर और 50fps तक, 20 सेकंड तक की क्लिप्स के साथ। Image-to-video और multi-keyframe conditioning built-in हैं, तो आप Pikaframes की तरह क्लिप में कई जगहों पर reference stills pin कर सकते हैं।

license ही पेच है, या नहीं है, आपके आकार पर निर्भर। LTX-2 research के लिए और $10M सालाना राजस्व से कम के commercial इस्तेमाल के लिए मुफ़्त है। उससे ऊपर आपको एक commercial license चाहिए, इसलिए यह सख़्त अर्थ में open source के बजाय open weights है। मौजूदा checkpoint LTX-2.3 एक 22B पैरामीटर अपडेट है जिसमें audio और prompt adherence बेहतर है। Weights, distilled 8-step variants, LoRA adapters, और ComfyUI तथा Diffusers integrations के साथ Hugging Face पर हैं, और hosted APIs LTX platform, fal.ai, और Replicate पर चलते हैं।

CogVideoX (Tsinghua/Zhipu AI)

CogVideoX एक 3D causal VAE इस्तेमाल करता है जो sequence length घटाता है और flickering रोकता है। adaptive LayerNorm transformer text-video alignment बेहतर करता है। native Diffusers इंटीग्रेशन के साथ 2B (Apache 2.0) और 5B (research license) variants में उपलब्ध।

क्लिप्स 720x480 पर 6-10 सेकंड की हैं। छोटी, पर quality-to-compute अनुपात अच्छा है और यह एक 12GB GPU पर चलता है।

First-Frame बनाम असली Reference: मुख्य फ़र्क़

हर "reference image" सपोर्ट एक जैसा नहीं होता। सही मॉडल चुनने के लिए इस फ़र्क़ को समझना बेहद ज़रूरी है।

First-frame मॉडल (LongCat, Helios, Hailuo, Luma Ray2, HunyuanVideo) आपकी image को literal opening frame मानते हैं। मॉडल उसी सटीक visual से आगे की ओर animate करता है। आप किसी किरदार का headshot अपलोड करके उसे किसी अलग सीन में नहीं बता सकते। image ही सीन है।

असली reference मॉडल (Kling, Grok Imagine, Seedance, SkyReels V3) आपकी image से पहचान निकालते हैं और उस किरदार/object को आपके बताए किसी भी सीन में रख देते हैं। किसी व्यक्ति की फ़ोटो अपलोड करें, फिर prompt करें "वह व्यक्ति सूर्यास्त के समय जंगल से गुज़रता है।" किरदार अपनी पहचान बनाए रखते हुए पूरी तरह नए environment में दिखता है। adventure movie जैसे multi-scene narrative content के लिए आपको यही चाहिए।

Character ID मॉडल (Sora 2 Pro) static images के बजाय वीडियो क्लिप्स से पहचान निकालते हैं। आप एक बार एक टिकाऊ character ID बनाते हैं और उसे असीमित भविष्य की जनरेशनों भर में दोबारा इस्तेमाल करते हैं।

Style/ingredient मॉडल (Veo 3.1) reference images का इस्तेमाल खास किरदार पहचान निकालने के बजाय visual style, textures, और समग्र लुक को प्रभावित करने के लिए करते हैं। किसी प्रोजेक्ट भर में visual consistency बनाए रखने के लिए अच्छे, अलग-अलग किरदार control के लिए कम सटीक।

10-मिनट के वीडियो के लिए असली Workflow

2026 के मध्य में चीज़ें कहाँ खड़ी हैं, इसका ईमानदार आकलन यहाँ है। कोई भी अकेला मॉडल एक ही बार में भरोसेमंद तरीके से 10 मिनट का सुसंगत, उच्च-क्वालिटी वीडियो नहीं बनाता। LongCat Video 15 मिनट के दावों के साथ सबसे करीब पहुँचता है, पर उन लंबाइयों पर क्वालिटी और coherence काफ़ी बदलती है। Helios और SkyReels V2 क्रमशः "मिनट-स्तर" और "असीमित-लंबाई" का वीडियो बनाते हैं, पर outputs को सावधानीपूर्वक prompting और अक्सर कई कोशिशों की ज़रूरत होती है।

5-15 मिनट के वीडियो बनाने वाले ज़्यादातर creators के लिए जो workflow सचमुच काम करता है वह कई तरीकों को जोड़ता है:

Talking head / avatar content के लिए: LongCat Video का 2026 audio-driven मोड या SkyReels V3 का avatar जनरेशन एक सुसंगत बोलते किरदार के 5+ मिनट बना सकता है। यह "बटन दबाओ, लंबा वीडियो पाओ" के सबसे करीब है।

कई सीनों वाले narrative content के लिए (adventure movie शैली): असली character reference images के साथ Kling 3.0, Grok Imagine, या Seedance 2.0 इस्तेमाल करें। हर एक 10-15 सेकंड के अलग-अलग shots बनाएँ। किरदार की पहचान बनाए रखने के लिए हर जनरेशन भर में वही @Element या <IMAGE> references इस्तेमाल करें। multi-shot मोड (Kling प्रति call 6 shots सपोर्ट करता है) या extend API का इस्तेमाल करके shots को आपस में जोड़ें। इस workflow के लिए Kling सबसे ज़्यादा आज़माया-परखा है। Grok Imagine का "reference मोड" और "first-frame मोड" के बीच स्पष्ट अलगाव इसे एक मज़बूत विकल्प बनाता है। Seedance 2.0 सबसे ज़्यादा reference inputs (12 files) स्वीकार करता है पर नया है और कम परखा हुआ है।

कई क्लिप्स भर में character consistency के लिए: Sora 2 Pro का टिकाऊ character_id सिस्टम बहुत लंबे प्रोजेक्ट्स के लिए सबसे साफ़ तरीका है। एक बार किसी छोटे वीडियो से किरदार निकालें, फिर उस ID को reference करते हुए दर्जनों क्लिप बनाएँ। किरदार की पहचान समय के साथ बिगड़ती नहीं क्योंकि यह एक टिकाऊ embedding के तौर पर संग्रहीत होती है, हर बार किसी image से दोबारा व्याख्या नहीं होती।

Style-transferred content के लिए: fal.ai पर Lucy Restyle motion को बनाए रखते हुए AI style बदलाव लागू करके 30 मिनट तक के मौजूदा वीडियो को process करता है। अगर आपके पास source footage है, तो यह जनरेशन लंबाई की समस्या को पूरी तरह किनारे कर देता है। source वीडियो के प्रति सेकंड $0.01।

ओपन-सोर्स pipelines के लिए: Wan 2.1 या Helios पर एक video continuation loop के साथ बनाएँ। एक क्लिप बनाएँ, आख़िरी frame को अगली क्लिप के start frame के तौर पर इस्तेमाल करें, दोहराएँ। ComfyUI workflows इसे स्वचालित करते हैं। कई iterations पर consistency बिगड़ती है पर यह मुफ़्त और controllable है।

मूल चुनौती बनी रहती है: असली reference image सपोर्ट के साथ भी, दर्जनों क्लिप्स भर में character drift बढ़ता जाता है। चेहरे की विशेषताएँ, बाल, कपड़े, और त्वचा का रंग धीरे-धीरे बदलते हैं। उपाय (उच्च-क्वालिटी reference photos, सुसंगत prompting, shot batching) ज़रूरी हैं। पर Kling और Grok Imagine जैसे मॉडल जो किरदार की पहचान को सीन composition से अलग करते हैं, इसे first-frame-only मॉडलों से कहीं ज़्यादा आसान बना देते हैं।

3D Scaffold तरीका: कम पर Render, ऊँचा Transform

एक workflow जोर पकड़ रहा है जो ज़्यादातर long-form जनरेशन समस्याओं को पूरी तरह किनारे कर देता है। किसी AI मॉडल से शून्य से 10 मिनट का वीडियो बनवाने के बजाय, आप सही camera work, character blocking, और timing के साथ एक low-fidelity 3D cutscene render करते हैं, फिर उसे reference images और एक enhancement prompt के साथ video-to-video मॉडल से गुज़ारते हैं। 3D engine संरचना संभालता है। AI सौंदर्य संभालता है।

यह इसलिए काम करता है क्योंकि V2V transformation पूरी जनरेशन से कहीं संकरी समस्या है। मॉडल को camera motion, किरदार रखना, या सीन composition गढ़ने की ज़रूरत नहीं होती। उसे बस मौजूदा footage को आपके visual references का पालन करते हुए photorealistic बनाना होता है। यह कहीं ज़्यादा संभव है, और यह किसी भी लंबाई तक scale करता है जो आपका 3D engine render कर सके।

यह क्यों काम करता है

आपका 3D engine आपको वह सब देता है जिससे AI वीडियो मॉडल अभी भी जूझते हैं: सटीक camera control, frame भर में किरदार का बिल्कुल सही placement, सही physics interactions, और मिनटों की footage भर में सुसंगत timing। Dolly zooms, tracking shots, इशारे पर किरदारों का frame में आना और जाना, ये सब 3D engine में आसान हैं, ये सब text-prompted जनरेशन में अविश्वसनीय हैं। V2V मॉडल का इकलौता काम है materials, lighting, और textures को photorealistic output में बदलना और साथ ही उस geometry और motion को बनाए रखना जो आप पहले ही परिभाषित कर चुके हैं।

Character consistency भी आसान हो जाती है। 50 अलग AI जनरेशनों भर में identity drift से लड़ने के बजाय, आप मॉडल को हर frame में वही 3D किरदार दिखा रहे हैं। reference images मॉडल को बताती हैं कि उस किरदार को आख़िरी output में कैसा दिखना चाहिए। यह हर बार शून्य से एक सुसंगत किरदार बनाने से सरल समस्या है।

और लंबाई अब कोई बाधा नहीं रही। Lucy Restyle एक ही call में 30 मिनट संभालता है। ComfyUI में Wan 2.1 किसी भी लंबाई को chunks में process कर सकता है। आप "मैं 10 मिनट कैसे बनाऊँ" वाली समस्या से बिल्कुल नहीं लड़ रहे क्योंकि footage पहले से मौजूद है।

RealMaster (Meta / Tel Aviv University)

RealMaster खास इसी workflow के लिए बना एक research सिस्टम है। मार्च 2026 में Meta Reality Labs और Tel Aviv University द्वारा प्रकाशित, यह render किए गए 3D वीडियो को photorealistic वीडियो में बदलता है और साथ ही source के साथ पूरी ज्यामितीय संरेखण बनाए रखता है।

यह तरीका संरचना और motion बनाए रखने के लिए 3D render से edge maps निकालता है, फिर बाक़ी सब कुछ photorealistic output में बदलने के लिए एक video diffusion मॉडल (VACE/Wan आर्किटेक्चर पर बना) लागू करता है। एक हल्का IC-LoRA adapter pipeline को एक single inference pass में distill कर देता है जिसे anchor frames की ज़रूरत नहीं होती और जो sequence के बीच में आने वाले objects को संभालता है।

GTA-V और CARLA simulator sequences पर परखा गया, RealMaster सामान्य-उद्देश्य video editing baselines से काफ़ी बेहतर प्रदर्शन करता है। यह realism transformation के ऊपर text prompt के ज़रिए मौसम के प्रभाव ("Make it rain", "Make it snow") भी परत-दर-परत जोड़ सकता है। मॉडल बिना retraining के simulators भर में सामान्यीकृत होता है। GTA-V data पर ट्रेन किए गए weights बिना किसी अतिरिक्त tuning के CARLA output पर काम करते हैं।

उपलब्धता: सिर्फ़ research। अभी कोई सार्वजनिक weights या API नहीं।

आज उपलब्ध Production V2V Tools

Element References के साथ Kling 3.0 V2V सबसे पूरा production विकल्प है। fal.ai पर Edit Video और Reference V2V endpoints element references (@Element1, @Element2, frontal और multi-angle फ़ोटो के साथ) तथा एक enhancement prompt के साथ-साथ 3-10 सेकंड के source video क्लिप स्वीकार करते हैं। मॉडल source में motion trajectories और camera patterns का विश्लेषण करता है, फिर मूल staging और camera work को बनाए रखते हुए आपकी बताई किरदार दिखावटों और visual style के साथ footage दोबारा बनाता है। 7 तक reference inputs। 1080p पर output। किरदार consistency बनाए रखने के लिए सभी chunks भर में वही element references के साथ अपने cutscene को 10-15 सेकंड के chunks में process करें।

Lucy Restyle 2 एक ही API call में $0.01 प्रति सेकंड input पर 30 मिनट तक का source वीडियो संभालता है। यह एक text prompt और style मार्गदर्शन के लिए एक वैकल्पिक reference image स्वीकार करता है। Kling जैसे प्रति-किरदार element references नहीं, पर एक पूरी लंबाई वाले 3D render के समग्र cinematic style transfer के लिए यह सबसे सरल और सस्ता रास्ता है। इसे अपना पूरा render और target लुक बताने वाला एक prompt दें। हज़ारों frames भर में temporal consistency के साथ 720p पर output।

ComfyUI में Wan 2.1 VACE ओपन-सोर्स रास्ता है। 14B VACE मॉडल reference-driven V2V करता है: एक source वीडियो और एक style reference image input करें, एक restyled version output करें जो संरचना और motion बनाए रखता है। Edge map conditioning संरचनात्मक निष्ठा बेहतर करता है। आप एक processing loop बना सकते हैं जो किसी भी लंबाई को सुसंगत style references के साथ chunks में संभालता है। मुफ़्त, आपके अपने hardware पर locally चलता है।

Grok Imagine V2V reference मोड में source वीडियो के साथ 1-7 reference images स्वीकार करता है। 720p पर $0.05 प्रति सेकंड। reference मोड और first-frame मोड के बीच स्पष्ट अलगाव का मतलब है कि आपके references source वीडियो की संरचना को override किए बिना किरदार की दिखावट का मार्गदर्शन करते हैं।

आपके 3D Render को क्या चाहिए

render quality का न्यूनतम स्तर मायने रखता है। एक नंगा wireframe V2V मॉडल को काम करने के लिए काफ़ी नहीं देगा। पर आपको production-quality materials या lighting की भी ज़रूरत नहीं है।

सही अनुपात और geometry। किरदार मॉडलों को reference images के सही mapping के लिए लगभग सही शरीर के अनुपात और चेहरे की बनावट चाहिए। सही अनुपात वाली बुनियादी humanoid geometry काफ़ी है। एक stick figure पहचानने लायक किरदार नहीं बनाएगा।

बुनियादी lighting direction। सीन की समग्र रोशनी तय करने वाली एक single directional light मॉडल को इच्छित मूड समझने में मदद करती है। AI विस्तार बढ़ाएगा और जोड़ेगा, पर उसे जानना ज़रूरी है कि सीन उजली दिन की रोशनी है या अँधेरा interior।

सहज camera motion। स्थिर, सोचे-समझे camera moves अच्छी तरह translate होते हैं। अनियमित या बेहद तेज़ motion V2V मॉडलों को भ्रमित कर सकती है। अपने virtual camera को असली camera की तरह व्यवहार करने दें।

Wireframe के बजाय flat shading। सरल flat-shaded या low-poly geometry wireframes या बिना texture वाले मॉडलों से बेहतर नतीजे देती है। सतहों पर बुनियादी ठोस रंग भी मॉडल को material boundaries समझने में मदद करते हैं।

Cost और Scale

अलग-अलग tools के ज़रिए 10-मिनट के cutscene को process करना:

पूरी लंबाई की processing के लिए Lucy Restyle सबसे सस्ता है। element references के साथ किरदार-विशिष्ट enhancement के लिए Kling सबसे सटीक है। अगर आपके पास hardware है तो Wan 2.1 मुफ़्त है (720p पर 14B मॉडल के लिए लगभग 60GB VRAM चाहिए, या कम क्वालिटी पर 1.3B variant के लिए 8GB)।

तुलना तालिका

आगे क्या आ रहा है

2026 भर की दिशा साफ़ है। LongCat Video ने साबित किया कि एक ओपन मॉडल में consistency के साथ मिनट-स्तर का जनरेशन मुमकिन है। Helios ने दिखाया कि यह real-time में हो सकता है। Seaweed APT2 ने interactive long-form जनरेशन का प्रदर्शन किया। और असली-reference मॉडलों (Kling, Grok, Seedance) ने साबित किया कि किरदार की पहचान मनमाने सीनों भर में टिक सकती है।

अगला कदम इन क्षमताओं को जोड़ना है: native long-form जनरेशन असली character reference सपोर्ट के साथ। अभी आप एक या दूसरा चुनते हैं। जब कोई मॉडल reference images से किरदारों को दर्जनों सीन बदलावों भर में बनाए रखते हुए 5 मिनट का वीडियो बना सकेगा, तब chained-clips workflow अप्रचलित हो जाएगा। Seedance 2.5 के घोषित specs (native 30-सेकंड क्लिप्स, 50 तक reference files, API 16 जुलाई 2026 को खुलना) उस दिशा में पहला असली कदम हैं।

जुलाई 2026 के मध्य तक, Artificial Analysis text-to-video arena (audio के साथ) की अगुवाई Google का Gemini Omni Flash (~1,240 Elo) करता है, उसके बाद Seedance 2.0, Alibaba का API-only Wan 2.7, और HappyHorse मॉडल, जबकि Kling 3.0 variants, SkyReels V4, और Veo 3.1 ठीक पीछे हैं। Leaderboard बार-बार बदलता है, इसलिए किसी भी अकेली रैंकिंग को एक तय क्रम के बजाय एक snapshot मानें।

3D scaffold तरीका एक समानांतर दिशा देता है। जैसे-जैसे V2V मॉडल अपनी संरचनात्मक सुरक्षा और photorealism बेहतर करते हैं, low-fidelity 3D renders को बेहतर बनाना पूरी production के लिए तेज़ी से व्यवहार्य होता जा रहा है। Meta का RealMaster पहले ही game engine output पर research-quality sim-to-real transformation हासिल कर लेता है। जब यह क्षमता reference image सपोर्ट के साथ production APIs तक पहुँचेगी, तब बुनियादी 3D कौशल वाला कोई भी व्यक्ति किसी भी अवधि पर camera, staging, और किरदार placement पर पूरे नियंत्रण के साथ photorealistic long-form वीडियो बना सकेगा।

फ़िलहाल, व्यावहारिक जवाब आपके use case पर निर्भर करता है:

Multi-character reference के लिए सबसे बेहतर: Kling 3.0 (अलग element + style सिस्टम के साथ 7 तक refs) या Seedance 2.0 (12 तक multimodal inputs, Seedance 2.5 API 16 जुलाई 2026 को खुलने पर 50 तक बढ़कर)।

Reference-to-video के लिए सबसे बेहतर API: Grok Imagine (साफ़ API, स्पष्ट reference मोड, $0.05/sec) या fal.ai के ज़रिए Kling ($0.084-0.112/sec)।

कई क्लिप्स भर में टिकाऊ किरदारों के लिए सबसे बेहतर: Kling 3.0 के element references या SkyReels V3 का reference-and-extend। (Sora 2 Pro का character-ID सिस्टम सबसे साफ़ तरीका था, पर यह 2026 में बंद हो रहा है, इसलिए इस पर नया काम शुरू न करें।)

सबसे बेहतर ओपन सोर्स: SkyReels V3 (1-4 असली reference images, असीमित लंबाई) या Helios (real-time, Apache 2.0)।

कच्ची अवधि के लिए सबसे बेहतर: LongCat Video (~15 min, पर सिर्फ़ first-frame)।

3D render enhancement के लिए सबसे बेहतर: Kling 3.0 V2V (प्रति-किरदार element refs, 1080p) या Lucy Restyle 2 (30 min input, $0.01/sec)।

आम सवाल

लंबे वीडियो के लिए सबसे बेहतर AI वीडियो मॉडल कौन सा है?

कच्ची अवधि के लिए, LongCat Video native रूप से लगभग 15 मिनट बनाता है, हालाँकि यह सिर्फ़ first-frame है। सुसंगत किरदारों वाले लंबे वीडियो के लिए, 2026 में व्यावहारिक जवाब एक reference-and-extend workflow है: किसी ऐसे मॉडल से क्लिप बनाएँ जिसमें मज़बूत reference सपोर्ट हो (Kling 3.0, Runway Gen-4.5, या ओपन-सोर्स SkyReels V3), फिर उन्हें chain करें। कोई भी अकेला मॉडल लंबा भी चलता हो और किरदार की पहचान भी पूरी तरह बनाए रखता हो, ऐसा नहीं है, इसलिए ज़्यादातर production काम इन्हें जोड़ता है।

कौन से AI वीडियो मॉडल reference images सपोर्ट करते हैं?

commercial विकल्पों में Kling 3.0 Omni, Runway Gen-4.5, Seedance 2.0, Google Veo 3.1, और Gemini Omni Flash सभी reference images सपोर्ट करते हैं। ओपन-सोर्स की तरफ़, SkyReels V2/V3, Wan 2.1, और LTX-2 reference inputs स्वीकार करते हैं जिन्हें आप खुद चला सकते हैं। सपोर्ट की क्वालिटी काफ़ी बदलती है, इसीलिए ऊपर की गाइड उन्हें tiers में बाँटती है।

क्या AI एक लंबे वीडियो भर में एक सुसंगत किरदार बना सकता है?

हाँ, पर एक ही बार में नहीं। भरोसेमंद तरीका यह है कि एक किरदार को एक या ज़्यादा reference images से lock करें, छोटी क्लिप बनाएँ, और वही references दोबारा देते हुए उन्हें extend या stitch करें। यहाँ असली reference सपोर्ट (मॉडल नई जनरेशनों भर में पहचान बनाए रखता है) first-frame conditioning से कहीं ज़्यादा मायने रखता है, जो सिर्फ़ opening frame को seed करता है।

First-frame और असली reference image सपोर्ट में क्या फ़र्क़ है?

First-frame conditioning आपकी image को क्लिप का literal opening frame इस्तेमाल करता है, फिर वीडियो आगे बढ़ने के साथ drift करता है। असली reference सपोर्ट image को एक identity anchor मानता है जिसका मॉडल पूरे जनरेशन भर में सम्मान करता है, ताकि कोई किरदार या style पूरी क्लिप भर में और अलग क्लिप्स भर में सुसंगत रहे। ऊपर का सेक्शन बताता है कि कौन सा मॉडल क्या करता है।

और पढ़ने के लिए

• Frontier Open-Source Gen AI Models — video, image, 3D, audio और अन्य के लिए ओपन-सोर्स जनरेटिव AI की व्यावहारिक गाइड
• Video Generator — Kling 3.0 Pro से संचालित हमारा video जनरेशन tool
• Sketch से animated 3D किरदार तक कैसे पहुँचें — किरदार animation के लिए image और video जनरेशन का इस्तेमाल

Perlin noise के साथ हाइटमैप प्रोसीजरल टेरेन के लिए डिफ़ॉल्ट शुरुआती पॉइंट हैं। fBm के कुछ octaves लेयर करें, एक कलर ग्रेडिएंट लगाएं, और आपके पास कुछ ऐसा है जो टेरेन जैसा दिखता है। हर ट्यूटोरियल यहीं खत्म होता है। लेकिन असली लैंडस्केप स्टैक किए हुए नॉइज़ जैसे नहीं दिखते। उनमें पानी से कटी हुई नदी घाटियां होती हैं, स्ट्रेस फ्रैक्चर से बनी चट्टानों की सतहें होती हैं, और लाखों सालों के कटाव से बनी गुफाएं और मेहराब होते हैं। उनमें कोरिलेटेड टेक्सचर होते हैं (समतल जमीन पर घास, खड़ी ढलानों पर चट्टान, ट्रीलाइन के ऊपर बर्फ) जो उन्हीं फिजिकल प्रोसेस से उभरते हैं जिन्होंने ज्यामिति को आकार दिया।

यह गाइड बताती है कि नॉइज़ के बाद क्या आता है। फिजिकली ग्राउंडेड जेनरेशन मेथड, वॉल्यूमेट्रिक रिप्रेजेंटेशन जो गुफाओं और ओवरहैंग को संभालते हैं, डिफ्यूज़न-आधारित न्यूरल टेरेन सिंथेसिस, और GPU-ड्रिवन LOD और स्ट्रीमिंग पाइपलाइन जो इन सबको एक ब्राउज़र टैब में 60fps पर रेंडर करने के लिए चाहिए।

यहां सब कुछ हमारी खास बाधा को ध्यान में रखकर बनाया गया है: एक मल्टीप्लेयर ओपन वर्ल्ड जो WebGL 2 / WebGPU में चलता है, नेटवर्क पर स्ट्रीम होता है, और जिसे क्रिएटर एडिट कर सकते हैं।

हाइटमैप क्यों काफी नहीं हैं

एक हाइटमैप हर ग्रिड पॉइंट पर एक हाइट वैल्यू स्टोर करता है। यह एक 2D फंक्शन है: (x, z) दिया जाए, तो y लौटाओ। यह रिप्रेजेंटेशन कॉम्पैक्ट है, GPU-फ्रेंडली है, और रेंडर करने में तेज है। लेकिन इसकी कुछ बुनियादी सीमाएं हैं जो एक क्रिएटर वर्ल्ड के लिए मायने रखती हैं।

कोई गुफा या ओवरहैंग नहीं। एक हाइटमैप ऐसे टेरेन को रिप्रेजेंट नहीं कर सकता जहां एक पॉइंट की दो अलग-अलग हाइट हों। गुफाएं, मेहराब, चट्टानों के ओवरहैंग, सुरंगें और तैरते हुए द्वीप सब असंभव हैं। Minecraft, No Man's Sky और Deep Rock Galactic सभी को इसी कारण वॉल्यूमेट्रिक टेरेन चाहिए।

कोई वर्टिकल फीचर नहीं। हाइटमैप में एक खड़ी चट्टान की सतह लगभग अनंत ढलान होती है, जो भारी टेक्सचर स्ट्रेचिंग और कोलिज़न आर्टिफैक्ट पैदा करती है। असली चट्टानों में horizontal फीचर होते हैं (कगार, दरारें) जिन्हें एक हाइटमैप रिप्रेजेंट नहीं कर सकता।

नॉइज़ नॉइज़ जैसा ही दिखता है। fBm के 8 octaves और domain warping के साथ भी टेरेन में एक बनावटी गुणवत्ता रहती है। इसमें असली भूविज्ञान की दिशात्मक संरचना नहीं होती: रिज लाइन, ड्रेनेज नेटवर्क, sediment deposits, टेक्टोनिक फोल्ड। ये पैटर्न फिजिकल प्रोसेस से उभरते हैं, नॉइज़ फंक्शन से नहीं।

क्रिएटर एडिट सीमित हैं। अगर क्रिएटर सिर्फ हाइट बदल सकते हैं, तो वे सुरंग नहीं खोद सकते, गुफाएं नहीं बना सकते, या भूमिगत जगहें नहीं बना सकते। एक ऐसी दुनिया के लिए जिसे क्रिएटर सचमुच आकार दे सकें, टेरेन रिप्रेजेंटेशन को जोड़ने के साथ-साथ घटाने (subtraction) को भी सपोर्ट करना होगा।

समाधान हाइटमैप को पूरी तरह छोड़ देना नहीं है। टेरेन के 90% हिस्से के लिए जो एक साधारण सतह है, वे अब भी सबसे अच्छा रिप्रेजेंटेशन हैं। समाधान एक हाइब्रिड तरीका है: हाइटमैप बेस टेरेन के साथ वॉल्यूमेट्रिक ओवरले वहां जहां जटिल ज्यामिति चाहिए, असली लैंडफॉर्म के लिए फिजिकली करेक्ट जेनरेशन, और उस विविधता के लिए न्यूरल सिंथेसिस जो नॉइज़ हासिल नहीं कर सकता।

क्विक जवाब: हम असल में क्या बनाएंगे

गहराई में जाने से पहले, यह रहा डिसीजन फ्रेमवर्क। बाकी लेख हर हिस्से को समझाता है।

टेरेन रिप्रेजेंटेशन

एक हाइब्रिड हाइटमैप + SDF सिस्टम इस्तेमाल करें। हाइटमैप पूरी दुनिया को कवर करता है (सस्ता, कॉम्पैक्ट, आजमाया हुआ)। SDF वॉल्यूम सिर्फ वहां मौजूद होते हैं जहां गुफाओं, ओवरहैंग, या क्रिएटर-कार्व्ड फीचर की जरूरत हो (शायद 5-10% chunks)। इससे दुनिया का 90% हिस्सा हाइटमैप कॉस्ट पर रहता है, और जहां जरूरत हो वहां मनचाही ज्यामिति सपोर्ट होती है।

जेनरेशन पाइपलाइन

सर्वर-साइड एक chained प्रोसेस के रूप में चलाएं:

1. Terrain Diffusion (या टेक्स्ट प्रॉम्प्ट के लिए MESA) एक seed से बेस हाइटमैप जेनरेट करता है। यह नॉइज़ की जगह असली एलिवेशन डेटा पर ट्रेन किए गए भूगर्भीय रूप से असली लैंडफॉर्म देता है।
2. एनालिटिकल इरोज़न (stream power law) हाइटमैप को नदी नेटवर्क और रिजलाइन के साथ मिलीसेकंड में रिफाइन करता है।
3. TerraFusion या Geodiffussr हाइटमैप से कोरिलेटेड टेक्सचर जेनरेट करते हैं (या WebGL 2 fallback के लिए प्रोसीजरल slope/altitude नियम इस्तेमाल करें)।
4. Ecosystem सिमुलेशन वनस्पति घनत्व के नक्शे बनाता है।
5. Arenite-स्टाइल इरोज़न चट्टानों की सतहों, मेहराबों और गुफाओं के लिए SDF वॉल्यूम जेनरेट करता है, जहां टेरेन को उनकी जरूरत हो।
6. Chunk बनाएं, कंप्रेस करें, CDN पर अपलोड करें। औसत chunk: 2-8 KB। वॉल्यूमेट्रिक डेटा वाला जटिल chunk: 20-100 KB।

क्रिएटर इस पाइपलाइन के साथ पैरामीटर एडजस्ट करके ("ज्यादा गीला," "ज्यादा पहाड़ी," "गुफाएं जोड़ो"), इरादा स्केच करके, या ब्रश और SDF टूल से सीधे sculpt करके इंटरैक्ट करते हैं।

LOD स्ट्रेटजी

दोनों रास्ते pop-free ट्रांज़िशन के लिए vertex shader में geomorphing इस्तेमाल करते हैं। दोनों दूर की वनस्पति के लिए billboard impostor इस्तेमाल करते हैं। WebGPU रास्ता तेज है (3.5ms टेरेन बजट) लेकिन WebGL 2 रास्ता भी चलने लायक है (6.5ms)।

स्ट्रीमिंग

प्रोग्रेसिव लोडिंग: पहले टेरेन ज्यामिति (<100ms), दूसरे नंबर पर टेक्सचर (<300ms), तीसरे नंबर पर वनस्पति (<1s), चौथे नंबर पर वॉल्यूमेट्रिक डेटा (<3s)। प्लेयर की वेलोसिटी के आधार पर pre-fetch करें। मेमोरी बजट: कुल 256 MB टेरेन।

एडिटिंग

सरफेस sculpting के लिए हाइटमैप ब्रश (raise, lower, smooth, erode)। वॉल्यूमेट्रिक एडिटिंग के लिए SDF प्रिमिटिव (गुफाएं carve करें, मेहराब जोड़ें)। दोनों लोकल पर तुरंत होते हैं, 100-300ms में सर्वर के साथ sync होते हैं, और delta अपडेट के जरिए बाकी प्लेयर तक broadcast होते हैं।

किस क्रम में क्या बनाएं

महीना 1-2: geometry clipmaps के साथ हाइटमैप टेरेन। सिर्फ WebGL 2। CDN से स्ट्रीमिंग। प्रोसीजरल slope/altitude मटेरियल। इससे हर ब्राउज़र में स्क्रीन पर टेरेन आ जाता है। जेनरेशन के लिए नॉइज़ + एनालिटिकल इरोज़न इस्तेमाल करें (Terrain Diffusion रुक सकता है)।

महीना 3-4: वनस्पति और वातावरण। density maps से GPU-instanced घास और पेड़। दिन/रात के चक्र के साथ प्रोसीजरल आसमान। वातावरण की धुंध। Cascaded shadow maps। दुनिया एक जगह जैसी लगने लगती है।

महीना 5-6: क्रिएटर एडिटिंग। हाइटमैप ब्रश टूल। मल्टीप्लेयर टेरेन एडिट के लिए delta-आधारित sync। एक साथ एडिटिंग के लिए spatial locking। यहीं से क्रिएटर दुनिया को आकार देना शुरू करते हैं।

महीना 7-9: वॉल्यूमेट्रिक टेरेन और WebGPU रास्ता। गुफाओं और ओवरहैंग के लिए SDF ओवरले। WebGPU compute में marching cubes। LOD boundaries के लिए Transvoxel। SDF sculpting टूल। इससे पूरा क्रिएशन टूलकिट खुल जाता है।

महीना 10-12: न्यूरल जेनरेशन और पॉलिश। बेस हाइटमैप के लिए Terrain Diffusion या MESA। टेक्सचर के लिए TerraFusion/Geodiffussr। माइक्रो-डिटेल के लिए Phasor noise। anti-repetition के लिए Hex-tiling। Virtual texturing। Laplacian blending। टेरेन प्रोडक्शन क्वालिटी तक पहुंचता है।

इस क्रम का मतलब है कि 2 महीने बाद कुछ खेलने लायक मौजूद होता है, 4 महीने बाद कुछ सुंदर, 6 महीने बाद कुछ एडिट करने लायक, और 12 महीने बाद कुछ अत्याधुनिक।

बाकी लेख हर फैसले के पीछे की रिसर्च है।

हाइटमैप से आगे के टेरेन रिप्रेजेंटेशन

Signed Distance Fields (SDFs)

एक signed distance field 3D स्पेस में हर पॉइंट पर सबसे नज़दीकी सतह तक की दूरी स्टोर करता है। पॉज़िटिव वैल्यू बाहर हैं, नेगेटिव वैल्यू अंदर हैं, और zero-crossing खुद सतह है। SDF मनचाहे 3D आकार रिप्रेजेंट करते हैं, जिनमें गुफाएं, मेहराब और तैरती हुई ज्यामिति शामिल हैं।

एक SDF को मेश के रूप में रेंडर करने के लिए, आप zero-crossing को त्रिभुजों के रूप में निकालने के लिए marching cubes (या इसका एक वैरिएंट) चलाते हैं। मेश रिज़ॉल्यूशन ग्रिड रिज़ॉल्यूशन पर निर्भर करता है: एक 256x256x256 SDF ग्रिड 1-मीटर रिज़ॉल्यूशन पर लगभग एक chunk जितना टेरेन देता है।

ब्राउज़र इम्प्लीमेंटेशन: WebGPU marching cubes compute shaders के जरिए पूरी तरह GPU पर चलता है। Will Usher का webgpu-marching-cubes इम्प्लीमेंटेशन ब्राउज़र में रियल टाइम में एक 256^3 ग्रिड प्रोसेस करता है, और native-स्पीड परफॉर्मेंस हासिल करता है। यह एल्गोरिदम बेहद parallel है (हर cell अलग से प्रोसेस होती है), जो इसे GPU compute के लिए आदर्श बनाता है।

@compute @workgroup_size(4, 4, 4)
fn marchingCubes(@builtin(global_invocation_id) id: vec3<u32>) {
    let sdfValues = sampleSDF(id);
    let caseIndex = classifyCell(sdfValues);
    if (caseIndex == 0u || caseIndex == 255u) { return; }
    let triangles = lookupTriangulation(caseIndex);
    let vertices = interpolateEdges(sdfValues, triangles);
    appendToMeshBuffer(vertices);
}

स्टोरेज कॉस्ट: एक 256^3 SDF 8-bit quantized precision पर uncompressed 16 MB है। लेकिन ज्यादातर वॉल्यूम खाली है (सतह से दूर)। Run-length encoding या sparse octree स्टोरेज आमतौर पर इसे प्रति chunk 100-500 KB तक घटा देता है, जो हाइटमैप टेरेन के बराबर है।

एडिटिंग: SDF टेरेन स्वाभाविक रूप से एडिट करने लायक है। मटेरियल जोड़ना distance field पर एक min() ऑपरेशन है। मटेरियल हटाना (खोदना) एक negated आकार के साथ max() है। आकारों के बीच smooth blending smoothMin() इस्तेमाल करती है। ये ऑपरेशन compute shader में इंटरैक्टिव रेट पर चलते हैं।

Dual Contouring

Marching cubes vertices को ग्रिड edges पर रखता है, जिससे smooth सतहें बनती हैं लेकिन sharp फीचर (चट्टान के किनारे, चट्टान के कोने) खो जाते हैं। Dual contouring हर cell में एक vertex उस पोज़ीशन पर रखता है जो उस cell के अंदर सतह को सबसे अच्छे से दर्शाती है, और इस तरह sharp किनारे और कोने बचाता है।

इस एल्गोरिदम को हर ग्रिड पॉइंट पर distance field वैल्यू और सतह के normals (SDF का gradient) दोनों चाहिए। यह सबसे अच्छी vertex पोज़ीशन ढूंढने के लिए हर cell पर एक छोटी least-squares समस्या हल करता है। नतीजा एक ऐसी मेश है जो smooth टेरेन और sharp चट्टानी फीचर दोनों को पकड़ती है।

Neural Dual Contouring (Chen et al., 2022, arXiv:2202.01999) least-squares solver की जगह एक neural network रखता है जो सबसे अच्छी vertex पोज़ीशन और edge crossings की भविष्यवाणी करता है। यह बेहतर सतह reconstruction सटीकता और फीचर संरक्षण हासिल करता है, खासकर जटिल प्राकृतिक चट्टानी संरचनाओं के लिए।

Transvoxel एल्गोरिदम

वॉल्यूमेट्रिक टेरेन में सबसे कठिन समस्या मेश जेनरेट करना नहीं है। यह LOD ट्रांज़िशन हैं। जब एक हाई-रिज़ॉल्यूशन chunk एक लो-रिज़ॉल्यूशन chunk के बगल में होता है, तो boundary पर मेश आपस में मेल नहीं खातीं, जिससे दिखने वाली दरारें बनती हैं।

Transvoxel एल्गोरिदम, जिसे Eric Lengyel (transvoxel.org) ने डिज़ाइन किया, रिज़ॉल्यूशन के बीच की boundaries पर खास transition cells डालकर इसे हल करता है। ये cells अतिरिक्त त्रिभुजों के साथ रिज़ॉल्यूशन के फर्क को पाटती हैं जो दोनों तरफ से बिल्कुल मेल खाते हैं। यह एल्गोरिदम जटिल boundary समस्या को 73 equivalence classes तक घटा देता है (brute-force तरीके के लगभग 12 लाख मामलों की तुलना में)।

Transvoxel खास तौर पर रियल-टाइम एप्लिकेशन के लिए डिज़ाइन किया गया है जहां voxel डेटा डायनामिक रूप से बदलता है (क्रिएटर एडिट, इरोज़न, mining)। यह patent-free है और इसे शिप हुए गेम में इस्तेमाल किया गया है (Space Engineers, Astroneer)। एडिट करने लायक वॉल्यूमेट्रिक टेरेन वाली ब्राउज़र दुनिया के लिए, Transvoxel ही LOD समाधान है।

हाइब्रिड: हाइटमैप बेस + वॉल्यूमेट्रिक ओवरले

एक ब्राउज़र ओपन वर्ल्ड के लिए व्यावहारिक तरीका एक लेयर्ड सिस्टम है:

लेयर 1: हाइटमैप टेरेन पूरी दुनिया को कवर करता है। यह लहरदार पहाड़ियों, घाटियों और पर्वतों के लिए सस्ता, कॉम्पैक्ट रिप्रेजेंटेशन है। यह प्रति chunk छोटे हाइटमैप patches (हर एक 2-4 KB) के रूप में स्ट्रीम होता है। रेंडरिंग स्थिर GPU कॉस्ट के साथ geometry clipmaps इस्तेमाल करती है।

लेयर 2: वॉल्यूमेट्रिक ओवरले सिर्फ उन chunks में मौजूद होते हैं जहां जटिल ज्यामिति चाहिए। गुफाएं, चट्टानों की सतहें, मेहराब, क्रिएटर-कार्व्ड सुरंगें और भूमिगत जगहें sparse SDF वॉल्यूम के रूप में स्टोर होती हैं। सिर्फ वॉल्यूमेट्रिक डेटा वाले chunks ही SDF स्टोरेज और marching cubes कॉस्ट उठाते हैं।

लेयर 3: क्रिएटर बदलाव बेस लेयर के ऊपर SDF एडिट के रूप में स्टोर होते हैं। एक क्रिएटर जो सुरंग खोदता है, सुरंग का SDF आकार स्टोर करता है। रेंडरिंग सिस्टम हाइटमैप सतह को वॉल्यूमेट्रिक subtractions और additions के साथ मिलाकर अंतिम मेश बनाता है।

इस हाइब्रिड में समतल टेरेन की कीमत लगभग शून्य है (बस हाइटमैप), और यह सिर्फ वहीं स्केल करता है जहां जटिलता मौजूद हो। एक आम दुनिया में, शायद 5-10% chunks को वॉल्यूमेट्रिक डेटा की जरूरत होती है।

फिजिकली करेक्ट टेरेन जेनरेशन

नॉइज़ रैंडम टेरेन बनाता है। फिजिक्स असली टेरेन बनाता है। फर्क साफ दिखता है: नॉइज़ टेरेन में कोई संरचना नहीं होती (यह हर जगह रैंडम रूप से उबड़-खाबड़ है), जबकि फिजिकल टेरेन में नदी नेटवर्क, रिज लाइन, alluvial fans और cliff bands होते हैं जो इरोज़न और टेक्टोनिक्स से उभरते हैं।

Hydraulic इरोज़न: नींव

पानी ढलान पर बहता है, sediment उठाता है, और धीमा होने पर उसे जमा कर देता है। यह एकमात्र प्रोसेस, लाखों वर्चुअल सालों तक सिमुलेट किया जाए, तो बेरंग नॉइज़ को पहचाने जाने लायक भूगर्भीय फीचर वाले टेरेन में बदल देता है।

particle-आधारित तरीका हाइटमैप पर सिमुलेटेड बारिश की बूंदें गिराता है। हर बूंद ढलान पर बहती है (gradient का पीछा करते हुए), स्पीड और ढलान के आधार पर मटेरियल काटती है, घुले हुए भार के रूप में sediment ले जाती है, और वेलोसिटी घटने या क्षमता पार होने पर sediment जमा करती है। 200,000-500,000 particles के बाद टेरेन में बनते हैं:

• नदी घाटियां जो अधिकतम पानी के बहाव के रास्ते पर चलती हैं
• रिज लाइन जो drainage basins को अलग करती हैं
• Alluvial fans जहां खड़ी घाटियां समतल मैदानों में खुलती हैं
• V-आकार की घाटियां पहाड़ी टेरेन में, और U-आकार की हिमनद टेरेन में

GPU इम्प्लीमेंटेशन: particle सिमुलेशन parallelizable है। हर particle स्वतंत्र है (अनुमान particle-particle इंटरैक्शन को नजरअंदाज करता है, जो इरोज़न के लिए ठीक है)। एक WebGPU compute shader 60fps पर हर फ्रेम 10,000 particles प्रोसेस करता है, और 200,000 particles करीब 3 सेकंड के रियल टाइम में पूरे करता है।

Sebastian Lague का ओपन-सोर्स इम्प्लीमेंटेशन (GitHub) मानक शुरुआती पॉइंट है। यह C# में एक ही थ्रेड पर चलता है और एक 1024x1024 हाइटमैप को कुछ सेकंड में प्रोसेस करता है। GPU वर्ज़न 50-100x तेज है।

Thermal इरोज़न

पानी ही एकमात्र इरोज़न बल नहीं है। तापमान में बदलाव से चट्टान में दरार पड़ती है और वह टूटती है (thermal weathering)। जब दो टेरेन पॉइंट के बीच की ढलान किसी मटेरियल के angle of repose से ज्यादा हो जाती है, तो मटेरियल ऊंचे पॉइंट से नीचे वाले पॉइंट पर गिरता है। इससे बनते हैं:

• Talus slopes चट्टानों के आधार पर (गिरी हुई चट्टान के ढेर)
• Softened रिज लाइन समय के साथ
• मटेरियल पर निर्भर प्रोफाइल (कठोर चट्टान खड़ी ढलानें बनाए रखती है, नरम मिट्टी ढलकर हल्के कोण बनाती है)

Thermal इरोज़न hydraulic इरोज़न से सरल है। यह एक local ऑपरेशन है: हर cell के लिए, पड़ोसियों के साथ हाइट के फर्क की तुलना करें। अगर ढलान threshold से ज्यादा हो, तो मटेरियल नीचे की ओर ले जाएं। यह हर iteration पर एक ही compute shader पास के रूप में चलता है और 50-100 iterations में converge हो जाता है।

hydraulic और thermal इरोज़न को मिलाने से ऐसा टेरेन बनता है जो दोनों में से किसी एक की तुलना में नाटकीय रूप से ज्यादा प्राकृतिक दिखता है। पानी घाटियां काटता है, thermal इरोज़न उनके बीच की रिज को नरम करता है और घाटी के फर्श को मलबे से भरता है।

Stream Power Law: एनालिटिकल इरोज़न

हाल की रिसर्च particle-आधारित सिमुलेशन का एक विकल्प देती है। stream power law (एक भू-आकृति विज्ञान समीकरण जो इरोज़न रेट को drainage area और ढलान से जोड़ता है) को iteratively सिमुलेट करने के बजाय analytically हल किया जा सकता है।

Cordonnier et al. (2024, HAL) एनालिटिकल stream power law को landslide और hillslope diffusion प्रोसेस के साथ मिलाते हैं। नतीजा एक ऐसा टेरेन जेनरेशन है जो फिजिकली ग्राउंडेड है लेकिन एक टेम्पोरल सिमुलेशन के बजाय एक गणितीय फंक्शन के रूप में चलता है। आप एक नॉइज़-आधारित हाइटमैप और पैरामीटर (बारिश की दर, चट्टान की कठोरता, टेक्टोनिक uplift दर) डालते हैं और मिलीसेकंड में एक eroded टेरेन पाते हैं।

यह एनालिटिकल तरीका एक ब्राउज़र दुनिया के लिए आदर्श है क्योंकि यह टेरेन जेनरेशन के दौरान सर्वर-साइड एक बार चलता है, iteratively नहीं। पैरामीटर क्रिएटर ट्यून कर सकते हैं ("इस इलाके को ज्यादा पहाड़ी बनाओ" uplift दर एडजस्ट करता है, "इसे ज्यादा गीला करो" बारिश बढ़ाता है और घाटियों को गहरा करता है)।

Arenite: मल्टी-फिजिक्स इरोज़न (SIGGRAPH 2025)

Arenite (Project page) एक फिजिक्स-आधारित sandstone सिमुलेटर है जो साधारण शुरुआती परिस्थितियों से मेहराब, alcoves, hoodoos और buttes जेनरेट करता है। यूज़र erodability मैप पेंट करते हैं (नरम चट्टान बनाम कठोर चट्टान की लेयर) और वनस्पति, फिर सिस्टम सिमुलेट करता है:

• Stress distribution चट्टान के स्तंभ से होकर
• Wind इरोज़न जो खुले हुए नरम मटेरियल को प्राथमिकता से हटाता है
• Fluvial इरोज़न पानी के बहाव से
• Particle deposition जो नई संरचनाएं बनाता है

GPU इम्प्लीमेंटेशन एक डेस्कटॉप GPU पर जटिल संरचनाओं के लिए 5 मिनट से कम में चलता है। हालांकि यह रियल-टाइम ब्राउज़र इस्तेमाल के लिए बहुत धीमा है, यह सर्वर-साइड जेनरेशन के लिए काफी तेज है। एक क्रिएटर नरम/कठोर चट्टान की लेयर के साथ एक चट्टान की सतह तय कर सकता है और मिनटों में एक असली मेहराब संरचना पा सकता है।

आउटपुट एक 3D voxel field है, जो सीधे हमारी SDF/marching cubes पाइपलाइन में फिट हो जाता है।

रिप्रेजेंटेशन के पार Flexible इरोज़न

IRIT-STORM का 2024 का एक पेपर ("Flexible Terrain Erosion," Springer) एक व्यावहारिक समस्या हल करता है: ज्यादातर इरोज़न मेथड सिर्फ heightfields पर काम करते हैं। अगर आपका टेरेन voxels, SDFs, या लेयर्ड मटेरियल इस्तेमाल करता है, तो आपको हर एक के लिए अलग इरोज़न कोड चाहिए।

flexible इरोज़न मेथड इरोज़न को दो स्वतंत्र प्रोसेस में बांटता है: टेरेन alteration (सतह से मटेरियल हटाना) और material transport (बुनियादी फिजिक्स से चलने वाले particles के साथ sediment ले जाना)। हर particle का size, density, restitution और sediment क्षमता configurable होती है। एक वैकल्पिक vector field असली fluid dynamics के लिए particle की गति को नियंत्रित करता है।

क्योंकि particles एक unified material alteration इंटरफेस के जरिए टेरेन से इंटरैक्ट करते हैं, वही सिमुलेशन heightfields, voxel grids, implicit surfaces और लेयर्ड मटेरियल stacks पर काम करता है। हमारे हाइब्रिड टेरेन (हाइटमैप बेस + SDF ओवरले) के लिए, इसका मतलब है कि एक इरोज़न सिस्टम दोनों रिप्रेजेंटेशन संभालता है। particle सिमुलेशन GPU पर parallel चलता है।

River Networks और Drainage Basins

इरोज़न नदियां काटता है, लेकिन भरोसेमंद river networks जेनरेट करने के लिए सिर्फ पानी को ढलान पर बहाना काफी नहीं है। दो तरीके बेहतर नतीजे देते हैं:

Drainage-first जेनरेशन (Amit Patel, Red Blob Games, Project) एलिवेशन देने से पहले river network बनाता है। एक graph से शुरू करें (Voronoi या triangle mesh)। edges को रिज (कोई बहाव नहीं), entries (पानी अंदर आता है), या outlets (पानी बाहर जाता है) के रूप में वर्गीकृत करें। इससे असली drainage hierarchies बनती हैं जहां नदियां छोटी सहायक नदियों से मिलकर बड़ी जलधाराओं में बदलती हैं, और अलग-अलग नदी प्रकारों के लिए Rosgen classification system का पालन करती हैं (समतल टेरेन में braided channels, पर्वतों में संकरी घाटियां)।

Flow accumulation ट्रैक करता है कि हर टेरेन cell से कितना पानी गुजरता है। सिमुलेटेड बारिश को समान रूप से गिराएं, उसे ढलान पर बहाएं, और हर cell के visits गिनें। ज्यादा accumulation वाली cells नदी के channels हैं। मध्यम accumulation वाली cells मौसमी धाराएं हैं। accumulation मैप इरोज़न की तीव्रता (ज्यादा पानी = ज्यादा इरोज़न) और वनस्पति वितरण (नदी के किनारे ज्यादा गीले होते हैं, अलग पौधों की प्रजातियों को सहारा देते हैं) को भी चलाता है।

एक क्रिएटर दुनिया के लिए, river network टेरेन बनाते वक्त सर्वर-साइड जेनरेट होता है और प्रति chunk एक 2D flow direction मैप और एक water accumulation मैप के रूप में स्टोर होता है। ब्राउज़र क्लाइंट इन मैप का इस्तेमाल पानी की सतह रेंडर करने (नदी के channels में सही हाइट पर समतल plane) और वनस्पति वितरण चलाने (पानी के पास हरियाली ज्यादा) के लिए करता है।

Coastal और Shoreline जेनरेशन

समुद्र तट वे जगह हैं जहां टेरेन पानी से मिलता है, और इनमें खास फीचर होते हैं जो मानक इरोज़न नहीं बनाता: समुद्री चट्टानें, beach deposits, tidal flats, sea stacks और wave-cut platforms।

NEWTS1.0 (2024, MIT) दो इरोज़न तंत्रों का इस्तेमाल करके चट्टानी समुद्र तट के विकास को मॉडल करता है: uniform retreat (स्थिर इरोज़न दर) और wave-driven इरोज़न (fetch distance और incident wave angle के फंक्शन के रूप में इरोज़न दर)। यह मॉडल हजारों सिमुलेटेड सालों तक चलता है और headlands, खाड़ियां, sea stacks और मेहराब बनाता है जो असली coastal भू-आकृति विज्ञान से मेल खाते हैं।

एक ब्राउज़र दुनिया के लिए, coastal फीचर दुनिया बनाते वक्त पहले से जेनरेट होंगे। पैरामीटर (प्रमुख wave direction, तट के साथ चट्टान की कठोरता में बदलाव) क्रिएटर को उनके समुद्र तट का चरित्र नियंत्रित करने देते हैं। एक "Norwegian fjord" सेटिंग खड़ी किनारों वाली inlets बनाती है। एक "tropical atoll" सेटिंग lagoons के साथ नीची रेतीली तटरेखाएं बनाती है।

Cave और Underground जेनरेशन

गुफाओं को पूरी तरह वॉल्यूमेट्रिक टेरेन (SDFs या voxels) चाहिए क्योंकि हाइटमैप बंद जगहों को रिप्रेजेंट नहीं कर सकते। जेनरेशन के तरीके:

3D noise thresholding सबसे सरल मेथड है। हर voxel पर 3D Perlin या simplex noise sample करें। threshold से नीचे की वैल्यू ठोस हैं, ऊपर की खाली। threshold और noise पैरामीटर एडजस्ट करके सुरंग का व्यास, connectivity और chamber size नियंत्रित करें। इससे organic, कीड़े जैसी गुफा प्रणालियां बनती हैं जो Minecraft की याद दिलाती हैं।

PLUME (Procedural Layer Underground Modeling Engine) (2024, arXiv:2508.20926) लेयर्ड प्रोसीजरल नियमों का इस्तेमाल करके असली गुफा और lava tube वातावरण जेनरेट करता है। मूल रूप से अंतरिक्ष अन्वेषण रिसर्च के लिए बनाया गया (मंगल के lava tubes को सिमुलेट करते हुए), यह stalactites, columns और chamber systems के साथ भूगर्भीय रूप से संभव भूमिगत संरचनाएं बनाता है।

metaball carving के साथ L-system सुरंगें एक L-system grammar का इस्तेमाल करके टेरेन से होकर शाखाओं वाले सुरंग रास्ते उगाती हैं, फिर metaball implicit surfaces का इस्तेमाल करके असल सुरंग ज्यामिति carve करती हैं। metaballs smooth, गोल गुफा की दीवारें बनाते हैं। अलग-अलग पैरामीटर के साथ कई passes प्राथमिक रास्ते, साइड chambers और संकरी जोड़ने वाली सुरंगें बनाते हैं।

एक क्रिएटर दुनिया के लिए, cave जेनरेशन SDF ओवरले सिस्टम से जुड़ती है। बेस टेरेन एक हाइटमैप है (कोई गुफा नहीं)। जब किसी chunk को गुफाएं चाहिए (या तो प्रोसीजरल जेनरेशन से या क्रिएटर डिज़ाइन से), तो एक SDF वॉल्यूम जेनरेट होता है जो बेस टेरेन से cave ज्यामिति घटाता है। marching cubes पाइपलाइन मिली हुई सतह रेंडर करती है।

वनस्पति एक फिजिकल प्रोसेस के रूप में

गेम में वनस्पति आमतौर पर प्रोसीजरल रूप से ऐसे नियमों के साथ रखी जाती है जैसे "2000m से नीचे घास, 1500m से नीचे पेड़, 3000m से ऊपर बर्फ।" यह तेज है लेकिन एकसमान, गैर-असली वितरण बनाता है।

फिजिकली ग्राउंडेड वनस्पति सिमुलेशन हर पौधे को संसाधनों (रोशनी, पानी, मिट्टी के पोषक तत्व) के लिए प्रतिस्पर्धा करते हुए मॉडल करता है। सिमुलेशन:

1. बीज टेरेन पर बिखेरे जाते हैं
2. हर पौधा उपलब्ध संसाधनों के आधार पर बढ़ता है (पानी hydraulic इरोज़न सिमुलेशन से बहता है, धूप ढलान और aspect पर निर्भर करती है, मिट्टी की गहराई इरोज़न इतिहास पर निर्भर करती है)
3. पौधे प्रतिस्पर्धा करते हैं: पेड़ घास को छाया में डाल देते हैं, घना canopy नए seedlings को रोकता है
4. सिमुलेटेड समय के साथ, biomes स्वाभाविक रूप से उभरते हैं: पानी वाली घाटियों में जंगल, हवादार रिज पर विरल वनस्पति, जहां पानी जमा होता है वहां wetlands

Deussen et al. का ecosystem सिमुलेशन (Paper) ऐसे जंगल वितरण बनाता है जो असली पारिस्थितिक पैटर्न से मेल खाते हैं। सिमुलेशन एक 2D ग्रिड पर चलता है (प्रति टेरेन chunk एक cell) और density maps और species assignments बनाता है जिन्हें रेंडरिंग सिस्टम GPU instanced वनस्पति प्लेसमेंट के लिए इस्तेमाल करता है।

एक ब्राउज़र दुनिया के लिए, वनस्पति सिमुलेशन दुनिया जेनरेशन के दौरान एक बार चलता है (सर्वर-साइड)। आउटपुट प्रति chunk density maps का एक सेट है: tree density, grass density, flower density, rock debris density। ब्राउज़र क्लाइंट इन मैप को GPU instancing के साथ इस्तेमाल करके runtime पर वनस्पति बिखेरता है।

Diffusion-आधारित टेरेन सिंथेसिस

यहीं फील्ड सबसे तेजी से आगे बढ़ रहा है। Diffusion models (वही टेक्नोलॉजी जो images के लिए Stable Diffusion के पीछे है) टेरेन जेनरेशन पर लागू की जा रही है, और नतीजे नॉइज़-आधारित मेथड से काफी ज्यादा असली हैं।

Terrain Diffusion: Perlin Noise का उत्तराधिकारी

Terrain Diffusion (Goslin, 2025, arXiv:2512.08309, Project page) 1985 में Perlin noise के बाद से प्रोसीजरल टेरेन जेनरेशन में सबसे बड़ी प्रगति है। इस काम को बाद में SIGGRAPH 2026 में स्वीकार किया गया, और canonical arXiv शीर्षक अब "InfiniteDiffusion: Bridging Learned Fidelity and Procedural Utility for Open-World Terrain Generation" है। InfiniteDiffusion एल्गोरिदम और Terrain Diffusion फ्रेमवर्क एक ही पेपर के दो हिस्से हैं।

मुख्य नवाचार InfiniteDiffusion है, एक एल्गोरिदम जो unbounded domains के लिए diffusion sampling को नए सिरे से तैयार करता है। पारंपरिक diffusion models fixed-size आउटपुट बनाते हैं (जैसे एक 512x512 हाइटमैप)। InfiniteDiffusion अनंत विस्तार का टेरेन बनाता है, साथ में:

• Seed consistency: एक ही seed हमेशा वही टेरेन बनाता है, Perlin noise की तरह
• Constant-time random access: आप पड़ोसी इलाके पहले जेनरेट किए बिना किसी भी पॉइंट पर हाइट query कर सकते हैं
• कोई boundary artifacts नहीं: बिना दिखने वाले seams या repetition के अनंत जेनरेशन

सिस्टम diffusion models का एक hierarchical stack इस्तेमाल करता है। सबसे ऊपरी स्तर ग्रहीय-पैमाने के फीचर पकड़ता है (महाद्वीप, पर्वत श्रृंखलाएं)। हर अगला स्तर बारीक डिटेल जोड़ता है (अलग-अलग चोटियां, घाटियां, छोटे पैमाने का खुरदरापन)। एक compact Laplacian encoding समुद्र तल से हिमालय की चोटियों तक की विशाल dynamic range में आउटपुट को स्थिर करता है।

परफॉर्मेंस: जेनरेशन रियल-टाइम अन्वेषण के साथ कदम मिलाकर चलता है। पेपर रिपोर्ट करता है कि orbital velocity (करीब 7,700 m/s) के सैद्धांतिक चरम पर भी, टेरेन सिंथेसिस एक consumer GPU पर traversal से 9x तेज चलता है। प्रोजेक्ट में एक Minecraft integration शामिल है जो रियल-टाइम टेरेन सिंथेसिस दिखाता है।

यह हमारे लिए क्यों मायने रखता है: Terrain Diffusion असली दुनिया के एलिवेशन डेटा (पृथ्वी की असल भू-आकृति) पर ट्रेन किए गए लैंडस्केप बनाता है। आउटपुट में river networks, पर्वत श्रृंखलाएं, coastal फीचर और plateau संरचनाएं हैं जो training data से उभरती हैं, हाथ से ट्यून किए गए noise पैरामीटर से नहीं। एक क्रिएटर कह सकता है "Scottish Highlands जैसा टेरेन जेनरेट करो" और diffusion model कुछ सही भूगर्भीय चरित्र वाला बनाएगा।

मॉडल दुनिया जेनरेशन के दौरान सर्वर-साइड चलता है। आउटपुट एक मानक हाइटमैप है जो किसी भी अन्य टेरेन डेटा की तरह ब्राउज़र तक स्ट्रीम होता है। जेनरेशन मेथड क्लाइंट के लिए अदृश्य है।

TerraFusion: संयुक्त ज्यामिति और टेक्सचर

TerraFusion (2025, arXiv:2505.04050) हाइटमैप और टेरेन टेक्सचर को संयुक्त रूप से जेनरेट करके आगे जाता है। मुख्य अंतर्दृष्टि: टेरेन ज्यामिति और सतह का रूप कोरिलेटेड हैं (नदी के तल रेतीले होते हैं, चट्टान की सतहें चट्टानी, समतल इलाके घास वाले)। इन्हें अलग-अलग जेनरेट करने से बेमेल पैदा होता है।

TerraFusion हाइटमैप और टेक्सचर के लिए अलग VAEs के साथ एक latent diffusion model इस्तेमाल करता है, जो उनके joint distribution को मॉडल करने के लिए ट्रेन किया गया है। सिस्टम सपोर्ट करता है:

• Unconditional जेनरेशन: मैचिंग टेक्सचर के साथ रैंडम संभव टेरेन
• Sketch-conditioned जेनरेशन: एक क्रिएटर एक मोटा नक्शा बनाता है (यहां घाटियां, वहां रिज, इस किनारे चट्टानें) और मॉडल विस्तृत ज्यामिति और टेक्सचर जेनरेट करता है जो स्केच से मेल खाते हैं

एक क्रिएटर दुनिया के लिए, यह असरदार है। एक क्रिएटर अपने plot का सामान्य layout स्केच करता है, और सिस्टम उचित सतह मटेरियल के साथ भूगर्भीय रूप से संभव टेरेन भर देता है। कोई हाइटमैप painting नहीं, कोई texture splatting नहीं, कोई मैन्युअल material assignment नहीं।

MESA: Text-to-Terrain

MESA (2025, arXiv:2504.07210, CVPR 2025 Workshop) टेक्स्ट विवरण से टेरेन जेनरेट करता है। यह Copernicus प्रोग्राम के global remote sensing data पर ट्रेन किया गया है, इसलिए इसे हर तरह के स्थलीय लैंडस्केप का अनुभव है।

"steep granite walls वाला एक fjord जो एक चट्टानी समुद्र तट में खुलता है" जैसा एक प्रॉम्प्ट उचित भूगर्भीय संरचना के साथ एक हाइटमैप बनाता है। "हल्की पहाड़ियों और चौड़ी नदी घाटी वाली लहरदार खेती की जमीन" कुछ बिल्कुल अलग बनाता है।

MESA, Major TOM Core-DEM extension dataset पेश करता है, जो globally satellite imagery को digital elevation models के साथ जोड़ता है। यह training data मॉडल को यह समझ देता है कि असली टेरेन हर पैमाने पर और हर जलवायु क्षेत्र में कैसा दिखता है।

Geodiffussr: Text-Guided Terrain Texturing

Geodiffussr (2025, arXiv:2511.23029) एक मौजूदा हाइटमैप लेता है और एलिवेशन डेटा का सम्मान करते हुए टेक्स्ट विवरण से निर्देशित टेक्सचर जेनरेट करता है। "Autumn forest" मध्यम ढलानों पर नारंगी और सुनहरे पत्ते बनाता है और खड़ी सतहों पर खुली चट्टान। "Tropical coast" नीची जमीन पर palm वनस्पति बनाता है और समुद्र तल पर coral रेत।

सिस्टम multi-scale content aggregation इस्तेमाल करता है ताकि texture assignments एलिवेशन का सम्मान करें: बर्फ सिर्फ एक फिजिकली संभव ऊंचाई के ऊपर दिखती है, पानी के फीचर गड्ढों में बैठते हैं, ऊंचाई के साथ वनस्पति पतली होती है।

एक क्रिएटर दुनिया के लिए, इसका मतलब है कि टेरेन टेक्सचर को ज्यामिति बदले बिना एक टेक्स्ट प्रॉम्प्ट से फिर जेनरेट किया जा सकता है। एक क्रिएटर अपना मनचाहा टेरेन sculpt करता है, फिर mood का वर्णन करता है ("dark volcanic wasteland" या "lush temperate forest") और सिस्टम उचित सतह मटेरियल जेनरेट करता है।

ब्राउज़र टेरेन के लिए Dynamic LOD

बड़े टेरेन को हर जगह full resolution पर रेंडर करना एक ब्राउज़र में असंभव है। 1-मीटर रिज़ॉल्यूशन पर एक 4 km x 4 km दुनिया अकेले टेरेन की 1.6 करोड़ vertices है। Dynamic LOD इसे दुनिया के size की परवाह किए बिना एक स्थिर, संभालने लायक vertex count तक घटा देता है।

Geometry Clipmaps

Geometry clipmaps (Losasso और Hoppe, SIGGRAPH 2004, Paper) हाइटमैप टेरेन LOD के लिए gold standard बने हुए हैं। आइडिया: टेरेन को कैमरा पर केंद्रित concentric चौकोर rings के एक सेट के रूप में रेंडर करें। हर ring पिछले से दोगुने क्षेत्र का होता है लेकिन आधे रिज़ॉल्यूशन पर।

कैमरा के पास (सबसे अंदरूनी ring): full resolution, 1-मीटर ग्रिड spacing। एक ring बाहर: 2-मीटर spacing, 4x क्षेत्र को कवर करते हुए। अगला ring: 4-मीटर spacing, 16x क्षेत्र को कवर करते हुए। और ऐसे ही 6-8 स्तरों तक, जब तक सबसे बाहरी ring पूरी दृश्य दूरी को कवर न कर ले।

कुल vertex count स्थिर है: लगभग N^2 * levels, जहां N vertices में ring की चौड़ाई है। N=256 और 8 levels के साथ, यह कुल करीब 500K vertices है। यह वैसा ही रेंडर होता है चाहे दुनिया 1 km चौड़ी हो या 100 km।

ब्राउज़र इम्प्लीमेंटेशन: Geometry clipmaps WebGL 2 में काम करते हैं क्योंकि उन्हें सिर्फ मानक vertex buffer अपडेट चाहिए (कोई compute shaders नहीं)। जैसे कैमरा चलता है, CPU हर ring के लिए हाइटमैप डेटा को उचित रिज़ॉल्यूशन पर टेरेन sample करके अपडेट करता है। vertex shader एक texture से हाइट वैल्यू पढ़ता है और समतल ग्रिड को displace करता है।

Morphing: LOD स्तरों के बीच का ट्रांज़िशन नासमझी से संभाला जाए तो दिखने वाला "popping" बनाता है। Geomorphing (नीचे अपने सेक्शन में बताया गया) एक ट्रांज़िशन zone पर vertex shader में स्तरों के बीच vertex पोज़ीशन blend करता है, और बिना अतिरिक्त draw call कॉस्ट के smooth, pop-free ट्रांज़िशन बनाता है।

CDLOD: Quadtree-Adaptive Clipmaps

CDLOD (Strugar, 2014, Paper) fixed concentric rings के बजाय एक quadtree इस्तेमाल करके geometry clipmaps में सुधार करता है। quadtree टेरेन के मुताबिक ढलता है: समतल इलाके मोटे nodes इस्तेमाल करते हैं, जबकि हाई डिटेल वाले इलाके (चट्टानें, रिज) बारीक subdivision पाते हैं।

यह एक क्रिएटर दुनिया के लिए मायने रखता है क्योंकि अलग-अलग chunks की जटिलता अलग होती है। एक समतल घास का मैदान न्यूनतम रिज़ॉल्यूशन चाहता है। चट्टानों और गुफाओं वाला एक पहाड़ी इलाका अधिकतम डिटेल चाहता है। CDLOD रिज़ॉल्यूशन वहां allocate करता है जहां यह मायने रखता है।

CPU-साइड quadtree traversal हल्का है (कुछ सौ nodes) और तय करता है कि किस रिज़ॉल्यूशन पर कौन से टेरेन patches draw करने हैं। GPU हर patch को per-patch LOD uniforms के साथ एक instanced ग्रिड के रूप में रेंडर करता है।

Concurrent Binary Trees: Planetary-Scale Tessellation

Concurrent Binary Trees (CBT) adaptive टेरेन tessellation के लिए एक GPU-फ्रेंडली डेटा संरचना है, जिसे Benyoub और Dupuy (Intel, HPG 2024, Paper, GitHub) ने पेश किया।

मुख्य आइडिया: टेरेन को एक binary tree के रूप में दर्शाएं जहां हर node एक त्रिभुज है। Adaptive subdivision कैमरा के पास वाले त्रिभुजों को split करता है और दूर वाले त्रिभुजों को merge करता है। binary tree पूरी तरह GPU memory में एक 1D array (एक binary heap) के रूप में रहता है, और subdivision/merge ऑपरेशन compute shaders के रूप में चलते हैं।

2024 का पेपर CBT को चौकोर हाइटमैप domains से बढ़ाकर मनचाहे polygon meshes तक ले जाता है। इसका मतलब है आप एक sphere को tessellate कर सकते हैं (ग्रहीय रेंडरिंग के लिए) या एक मनचाहा बेस मेश (गैर-आयताकार सीमाओं वाली गेम दुनिया के लिए)। मुख्य सुधार: implicit encoding के बजाय CBT को एक memory pool manager के रूप में इस्तेमाल करना बहुत ज्यादा subdivision स्तरों की अनुमति देता है।

परफॉर्मेंस: console-स्तर hardware पर 0.2ms से कम में ग्रहीय-पैमाने का टेरेन tessellation। एल्गोरिदम processor count के साथ linearly स्केल करता है। WebGPU के लिए, यह एक ब्राउज़र में planet-scale टेरेन रेंडरिंग का एक रास्ता देता है, हालांकि इम्प्लीमेंटेशन की जटिलता ज्यादा है।

WebGPU के साथ GPU-Driven LOD

WebGPU एक पूरी तरह GPU-ड्रिवन टेरेन पाइपलाइन को सक्षम करता है जो LOD फैसलों में CPU की भागीदारी खत्म कर देती है:

1. Compute pass 1: Frustum और occlusion culling। एक compute shader हर टेरेन patch के bounding box को view frustum और एक occlusion buffer (पिछले फ्रेम का depth buffer, downsampled) के खिलाफ टेस्ट करता है। अदृश्य patches पूरी तरह हटा दिए जाते हैं।

2. Compute pass 2: LOD selection। दिखने वाले patches के लिए, screen-space size compute करें और उचित LOD स्तर चुनें। LOD स्तर और patch ID को एक indirect draw buffer में लिखें।

3. Compute pass 3: Mesh generation (वॉल्यूमेट्रिक टेरेन के लिए)। SDF डेटा वाले chunks के लिए, चुने हुए LOD रिज़ॉल्यूशन पर मेश जेनरेट करने के लिए marching cubes चलाएं।

4. Indirect draw। एक ही drawIndexedIndirect() कॉल सभी टेरेन patches रेंडर करता है। GPU सब कुछ तय करता है: क्या draw करना है, किस रिज़ॉल्यूशन पर, किस क्रम में।

इस पाइपलाइन की दुनिया के size या जटिलता की परवाह किए बिना स्थिर CPU कॉस्ट है (compute shaders dispatch करना और indirect draw call)। GPU हर patch के फैसले संभालता है।

@compute @workgroup_size(64)
fn lodSelection(@builtin(global_invocation_id) id: vec3<u32>) {
    let patchIdx = id.x;
    let bounds = patchBounds[patchIdx];

    if (!frustumTest(bounds, viewProjection)) { return; }
    if (occlusionTest(bounds, depthPyramid) == OCCLUDED) { return; }

    let screenSize = projectedSize(bounds, viewProjection, screenDimensions);
    let lod = clamp(u32(log2(maxScreenSize / screenSize)), 0u, MAX_LOD);

    let drawIdx = atomicAdd(&drawCount, 1u);
    drawArgs[drawIdx] = DrawArgs(patchIdx, lod, indexCount[lod], indexOffset[lod]);
}

Geomorphing: Pop-Free LOD ट्रांज़िशन

टेरेन LOD में सबसे बड़ा विज़ुअल artifact popping है: जब एक patch LOD स्तर बदलता है तो vertices अचानक नई पोज़ीशन पर कूद जाती हैं। Geomorphing एक ट्रांज़िशन zone पर LOD स्तरों के बीच vertex पोज़ीशन को smoothly interpolate करके इसे खत्म करता है।

इम्प्लीमेंटेशन पूरी तरह vertex shader में रहता है। हर vertex अपनी current-LOD पोज़ीशन और अपनी next-coarser-LOD पोज़ीशन दोनों स्टोर करता है। जैसे कैमरा दूरी ट्रांज़िशन threshold पार करती है, एक morph factor दोनों के बीच blend करता है:

float morphFactor = smoothstep(lodNear, lodFar, distanceToCamera);
float morphedHeight = mix(fineLodHeight, coarseLodHeight, morphFactor);
gl_Position = viewProjection * vec4(worldPos.x, morphedHeight, worldPos.z, 1.0);

Hoppe का geometry clipmap पेपर (GPU Gems 2, Chapter 2) clipmap rings के लिए पूरा इम्प्लीमेंटेशन बताता है। morph zone हर ring का बाहरी 20% है। इस zone के अंदर, vertices smoothly अगले ring के रिज़ॉल्यूशन की ओर converge करती हैं। विज़ुअल असर: टेरेन ज्यामिति detail स्तरों के बीच snap होने के बजाय "पिघलती" है। आम कैमरा स्पीड पर, ट्रांज़िशन अदृश्य होता है।

Image-space blending (Scherzer et al., Paper) एक विकल्प है जो दो LOD स्तरों की रेंडर की गई images को screen space में blend करता है। यह ज्यादा चरम LOD फर्क (जैसे mesh-to-billboard ट्रांज़िशन) संभालता है लेकिन ट्रांज़िशन zone के लिए एक अतिरिक्त render pass की कीमत लेता है।

GPU-Driven Vegetation Culling

वनस्पति (पेड़, घास, चट्टानें) अक्सर एक ओपन वर्ल्ड में draw calls का सबसे बड़ा स्रोत होती है। एक नासमझ तरीका हर फ्रेम हर वनस्पति instance draw करता है। GPU-ड्रिवन culling, जो अब Three.js में WebGPU के जरिए उपलब्ध है, अदृश्य instances को rasterizer तक पहुंचने से पहले खत्म कर देता है।

Three.js का ComputeInstanceCulling (Docs) instanced meshes के लिए frustum और LOD culling देता है, और बड़े instance counts के लिए 10-100x परफॉर्मेंस फायदा देता है। पाइपलाइन:

1. एक compute shader सभी instance bounding spheres पढ़ता है
2. हर एक को कैमरा frustum के खिलाफ टेस्ट करता है (6-plane test)
3. distance-आधारित LOD लगाता है: एक threshold से परे के instances कम detail पर स्विच करते हैं या पूरी तरह cull हो जाते हैं
4. बचे हुए instances एक buffer में compact होते हैं और drawIndirect के जरिए draw होते हैं

CPU per-instance शून्य काम करता है। शुरुआती setup के बाद, instance count की परवाह किए बिना कॉस्ट प्रति वनस्पति प्रकार एक compute dispatch और एक indirect draw call है।

घनी वनस्पति के लिए, Three.js का IndirectBatchedMesh (Docs) कई ज्यामिति प्रकारों (पेड़, झाड़ियां, चट्टानें) को एक ही buffer में पैक करता है और उन्हें multi-draw indirect के साथ draw करता है। एक chunk की सारी वनस्पति के लिए एक draw call।

हमारे वनस्पति सिस्टम के density-map-आधारित scattering के साथ मिलाकर, इसका मतलब है: density मैप एक compute shader में 50,000 घास के तिनकों की पोज़ीशन बनाता है, culling pass उन 70% को खत्म करता है जो off-screen हैं या बहुत दूर, और एक indirect draw call बचे हुए 15,000 तिनके रेंडर करता है। कुल CPU कॉस्ट: नगण्य।

वॉल्यूमेट्रिक टेरेन के लिए LOD

वॉल्यूमेट्रिक टेरेन (SDF + marching cubes) को अपने ही LOD सिस्टम की जरूरत है क्योंकि मेश जेनरेट होती है, पहले से authored नहीं। तरीका:

Multi-resolution SDF storage। SDF को एक mipmap जैसी hierarchy में कई रिज़ॉल्यूशन पर स्टोर करें। Level 0 full resolution है (1-मीटर voxels)। Level 1, 2-मीटर voxels है (8x कम डेटा)। Level 2, 4-मीटर voxels है। हर स्तर पर, SDF न्यूनतम absolute distance लेकर downsample होता है।

LOD-selected marching cubes। चाहे गए LOD से मेल खाते SDF स्तर पर marching cubes चलाएं। पास के chunks level 0 इस्तेमाल करते हैं। दूर के chunks level 2 या 3 इस्तेमाल करते हैं। Transvoxel एल्गोरिदम अलग-अलग स्तरों के बीच की boundary संभालता है।

Caching। जेनरेट की गई meshes तब तक कैश रहती हैं जब तक SDF न बदले (क्रिएटर एडिट) या LOD स्तर न बदले (कैमरा काफी हिला)। स्थिर टेरेन के लिए, मेश एक बार जेनरेट होकर फिर इस्तेमाल होती है।

टेरेन के लिए Streaming आर्किटेक्चर

Chunk डेटा फॉर्मेट

हर टेरेन chunk (64x64 मीटर) एक compact binary package के रूप में स्ट्रीम होता है:

ChunkPacket {
  header: {
    chunkX: i16, chunkZ: i16,
    version: u32,
    flags: u8  // hasHeightmap | hasVolumetric | hasVegetation
  }
  heightmap: {
    resolution: u8,      // 65x65 for full, 33x33 for half, 17x17 for quarter
    quantizedHeights: u16[resolution * resolution],  // delta-encoded, zlib compressed
    splatMap: u8[4 * resolution * resolution]         // RGBA blend weights, LZ4 compressed
  }
  volumetric?: {         // only present if flags.hasVolumetric
    sdfResolution: u8,   // typically 32 or 64
    sparseOctree: bytes  // run-length encoded sparse SDF
  }
  vegetation?: {         // only present if flags.hasVegetation
    treeDensityMap: u8[16 * 16],    // 4m resolution density grid
    grassDensityMap: u8[32 * 32],   // 2m resolution density grid
    rockDensityMap: u8[16 * 16]
  }
  creatorObjects: {
    count: u16,
    objects: PlacedObject[]   // assetId + transform + properties, ~40 bytes each
  }
}

आम size:

• सिर्फ हाइटमैप वाला chunk (समतल टेरेन): 2-4 KB compressed
• हाइटमैप + वनस्पति: 4-8 KB
• हाइटमैप + वॉल्यूमेट्रिक + वनस्पति (जटिल chunk): 20-100 KB
• 5x5 full-detail neighborhood: कुल 50-500 KB

Progressive Chunk लोडिंग

Chunks दूरी, गति की दिशा और डेटा प्रकार के आधार पर प्राथमिकता क्रम में लोड होते हैं:

Priority 1 (तुरंत, <100ms): उन chunks के लिए हाइटमैप ज्यामिति जिनमें प्लेयर घुसने वाला है। टेरेन की सतह पहले दिखती है। सबसे कम रिज़ॉल्यूशन (प्रति chunk 17x17) पर भी, जमीन मौजूद रहती है।

Priority 2 (तेज, <300ms): Splat maps और टेरेन टेक्सचर। जमीन को रंग मिलता है।

Priority 3 (streaming, <1s): Full-resolution हाइटमैप upgrade। वनस्पति density maps। GPU instancing पेड़ और घास बनाता है।

Priority 4 (background, <3s): गुफाओं/ओवरहैंग वाले chunks के लिए वॉल्यूमेट्रिक SDF डेटा। marching cubes एक Web Worker में मेश जेनरेट करता है, buffer को main thread में transfer करता है।

Priority 5 (lazy, <10s): क्रिएटर-रखे ऑब्जेक्ट। संरचनाओं के लिए हाई-रिज़ॉल्यूशन टेक्सचर। फूल, छोटी चट्टानें, मलबा जैसे डिटेल ऑब्जेक्ट।

Predictive Pre-fetching

प्लेयर के एक chunk में घुसने का इंतजार न करें। वेलोसिटी के आधार पर अनुमान लगाएं कि वे कहां जा रहे हैं और पहले से लोड करें:

• चलने की स्पीड (5 km/h): 2 chunks आगे pre-fetch करें (128m)। आम broadband latency पर, यह 200-400ms का lead time है।
• दौड़ना/सवारी (15 km/h): 4 chunks आगे pre-fetch करें। load ring वेलोसिटी की दिशा के साथ shift होता है।
• उड़ना/fast travel: ट्रांज़िशन के दौरान रेंडरिंग रोकें। destination chunks को सर्वोच्च प्राथमिकता पर स्ट्रीम करें। जब पहले फ्रेम के लिए काफी डेटा मौजूद हो तो रेंडरिंग फिर शुरू करें।

pre-fetch सिस्टम ट्रैक करता है कि कौन से chunks cache में हैं, कौन से in-flight हैं (अनुरोध किए गए लेकिन अभी नहीं पहुंचे), और कौन से चाहिए। एक priority queue लंबित अनुरोधों को तात्कालिकता से sort करती है। जिन chunks से प्लेयर दूर जा चुका है, उनके अनुरोध रद्द करें।

Memory बजट और Eviction

एक ब्राउज़र टैब को डेस्कटॉप पर 2-4 GB मिलता है। टेरेन सिस्टम को इसके एक हिस्से के अंदर रहना होगा (बाकी रेंडरिंग, फिजिक्स, networking और JavaScript heap के लिए है)।

टारगेट बजट: सभी टेरेन डेटा के लिए 256 MB।

हमारे आम chunk sizes पर:

• Full-detail cached chunks: ~100 (10x10 neighborhood) हर एक 5-100 KB पर = raw डेटा के लिए 5-10 MB
• GPU टेरेन ज्यामिति: ~50 MB (दिखने वाले टेरेन के लिए vertex buffers, index buffers)
• टेरेन टेक्सचर: ~100 MB (KTX2 compressed, atlas-packed)
• वनस्पति instance buffers: ~50 MB (GPU instancing के लिए positions, rotations, scales)
• SDF वॉल्यूम और cached marching cubes meshes: ~50 MB

दृश्य range से परे के chunks पहले GPU memory से evict होते हैं (टेक्सचर, vertex buffers), फिर CPU cache से। raw हाइटमैप डेटा सबसे आखिर में जाता है क्योंकि इसे रखना सबसे सस्ता है और प्लेयर के पलटने पर इसका होना सबसे जरूरी।

Biome ट्रांज़िशन और Anti-Tiling

Smooth Biome सीमाएं

असली लैंडस्केप में biomes के बीच कड़े किनारे नहीं होते। एक जंगल किसी रेखा पर रुककर रेगिस्तान नहीं बन जाता। एक gradient होता है: घना जंगल पतला होकर बिखरे पेड़ों में बदलता है, फिर scrubland, फिर विरल रेगिस्तानी वनस्पति। इसे सही करना दुनिया को tiled के बजाय निरंतर महसूस कराता है।

AutoBiomes (Kötter et al., Paper) प्रोसीजरल टेरेन जेनरेशन को सरलीकृत जलवायु सिमुलेशन के साथ मिलाता है। तापमान, आर्द्रता और एलिवेशन हर पॉइंट पर biome प्रकार तय करते हैं। biomes के बीच, material weights और वनस्पति घनत्व एक ट्रांज़िशन zone (आमतौर पर 50-100 मीटर चौड़ा) पर interpolate होते हैं। ट्रांज़िशन की चौड़ाई biome जोड़ी के हिसाब से अलग होती है: forest-to-grassland चौड़ा और क्रमिक है, cliff-to-water संकरा और अचानक।

एक क्रिएटर दुनिया के लिए, biome assignment एक मोटे ग्रिड पर चलता है (प्रति 16x16 मीटर क्षेत्र एक biome sample)। टेरेन shader मौजूदा fragment और उसके पड़ोसियों के लिए biome वैल्यू पढ़ता है, ट्रांज़िशन zone में material weights interpolate करता है, और तदनुसार टेक्सचर blend करता है। वनस्पति scattering वही interpolated घनत्व वैल्यू इस्तेमाल करती है, इसलिए जंगल के किनारे पर tree density धीरे-धीरे fade होती है।

क्रिएटर नियंत्रण: क्रिएटर को अपने plots पर biome overrides पेंट करने दें। सिस्टम टेरेन गुणों से डिफ़ॉल्ट biomes जेनरेट करता है, लेकिन क्रिएटर उन्हें override कर सकते हैं। किसी नीची जगह पर "swamp" पेंट करें और मटेरियल गंदले पानी, काई और मरे हुए पेड़ों में बदल जाता है। biome paint मैप biome IDs का एक per-chunk 16x16 ग्रिड (256 bytes) है जो प्रोसीजरल assignment को override करता है।

Hex-Tiling: Texture Repetition खत्म करना

टेरेन रेंडरिंग में सबसे आम विज़ुअल artifact texture repetition है। एक 100-मीटर घास के मैदान पर tiled एक 1-मीटर घास texture दिखने वाले grid पैटर्न बनाती है। दो तकनीकें इसे ठीक करती हैं:

Hex-tiling (Mikkelsen, Demo) चौकोर tiling grid की जगह एक hexagonal grid रखती है। हर hexagonal tile texture को एक रैंडम offset और rotation पर sample करती है। seams छिपाने के लिए hexagonal सीमाओं को blend किया जाता है। नतीजा एक ऐसी सतह है जो tiled के बजाय एकसमान रूप से रैंडम दिखती है। कॉस्ट: प्रति fragment लगभग 3 अतिरिक्त texture samples। यह तकनीक production गेम में व्यापक रूप से इस्तेमाल होती है और किसी भी fragment shader में चलती है।

Stochastic texture filtering (Pharr et al., NVIDIA, 2024, Paper) shading से पहले के बजाय बाद में filtering लगाती है, stochastic sampling इस्तेमाल करते हुए। stochastic sampling से error न्यूनतम है और spatiotemporal denoising से अच्छे से संभाला जाता है। यह ज्यादा सटीक filtered नतीजे देता है और compressed/sparse टेक्सचर के साथ काम करता है। टेरेन के लिए, यह tiling artifacts और वे filtering artifacts दोनों खत्म करता है जो hex-tiling कभी-कभी ट्रांज़िशन पर पैदा कर सकती है।

एक ब्राउज़र दुनिया के लिए, hex-tiling व्यावहारिक विकल्प है (यह किसी भी shader में काम करती है)। Stochastic filtering को ज्यादा infrastructure चाहिए लेकिन अगर temporal denoising उपलब्ध हो (जो TAA के साथ एक WebGPU रास्ते में होगा) तो यह बेहतर नतीजे देती है।

टेरेन Material सिस्टम

Triplanar Mapping

मानक UV-mapped टेक्सचर खड़ी ढलानों पर भयानक रूप से खिंच जाते हैं क्योंकि UV coordinates compress होते हैं। Triplanar mapping टेक्सचर को तीनों axes (X, Y, Z) पर project करता है और सतह के normal के आधार पर blend करता है:

vec3 blending = abs(normal);
blending = normalize(max(blending, 0.00001));
blending /= (blending.x + blending.y + blending.z);

vec4 xaxis = texture(material, worldPos.yz * scale);
vec4 yaxis = texture(material, worldPos.xz * scale);
vec4 zaxis = texture(material, worldPos.xy * scale);

vec4 color = xaxis * blending.x + yaxis * blending.y + zaxis * blending.z;

चट्टान की सतहों को X या Z projection मिलता है (कोई stretching नहीं)। समतल जमीन को Y projection मिलता है। blending smooth और automatic है। कोई UV unwrapping जरूरी नहीं।

Babylon.js में एक built-in TriPlanar Material है। Three.js को एक custom shader चाहिए, लेकिन इम्प्लीमेंटेशन करीब 30 लाइन GLSL है।

PBR टेरेन के लिए, triplanar mapping को सभी channels पर लगाएं: albedo, normal, roughness और ambient occlusion। वही blending weights हर channel पर लागू होते हैं।

Slope और Altitude-आधारित Material Assignment

हाथ से splat maps पेंट करने के बजाय, टेरेन गुणों के आधार पर मटेरियल प्रोसीजरल रूप से assign करें:

float slope = acos(dot(normal, vec3(0, 1, 0)));
float altitude = worldPos.y;

float grassWeight = smoothstep(0.3, 0.0, slope) * smoothstep(2000.0, 1500.0, altitude);
float rockWeight = smoothstep(0.2, 0.5, slope);
float snowWeight = smoothstep(2500.0, 3000.0, altitude) * smoothstep(0.4, 0.1, slope);
float sandWeight = smoothstep(5.0, 0.0, altitude) * smoothstep(0.15, 0.0, slope);

नीची ऊंचाई पर समतल जमीन को घास मिलती है। खड़ी ढलानों को चट्टान। ऊंची ऊंचाई को बर्फ (लेकिन सिर्फ उन सतहों पर जो बर्फ जमा होने के लिए काफी समतल हों)। समुद्र तल के पास रेत। ट्रांज़िशन smooth और फिजिकली प्रेरित हैं।

एक क्रिएटर दुनिया के लिए, altitude thresholds और blend zones को प्रति chunk paintable पैरामीटर के रूप में expose करें। क्रिएटर treeline को ऊपर या नीचे ले जा सकते हैं, बर्फ की कवरेज बढ़ा सकते हैं, या अपने plot के लिए material नियम एडजस्ट करके एक घास वाली पहाड़ी को रेतीले रेगिस्तान में बदल सकते हैं।

GPU-Friendly Laplacian Texture Blending

मानक texture blending (लेयर के बीच linear interpolation) या तो दिखने वाले seams पैदा करती है या धुले-धुले, low-contrast नतीजे। Laplacian pyramid blending इसे हल करती है लेकिन पारंपरिक रूप से महंगी precomputation चाहती है।

Wronski (NVIDIA, 2025, JCGT) एक GPU-friendly वैरिएंट पेश करते हैं जो रियल-टाइम shaders में बिना precomputation और बिना अतिरिक्त memory के काम करता है। यह तकनीक मानक mipmap chain को Laplacian pyramid के एक अनुमान के रूप में इस्तेमाल करती है: texture को मौजूदा mip level और एक मोटे level दोनों पर sample करें, अंतर (Laplacian) compute करें, और हर लेयर से Laplacian योगदान blend करें।

नतीजा sharp local फीचर (अलग-अलग घास के तिनके, चट्टान की दरारें) बचाता है जबकि बड़े पैमाने पर smoothly blend करता है। कॉस्ट प्रति fragment कुछ अतिरिक्त texture taps है। ऐसे टेरेन के लिए जहां आप प्रति pixel 4+ material layers blend कर रहे हैं, यह linear blending से काफी बेहतर नतीजे देती है, खासकर घास, चट्टान और रेत के बीच के ट्रांज़िशन पर।

Erosion Detail के लिए Phasor Noise

मानक टेरेन अक्सर पास से देखने पर समतल दिखता है क्योंकि इरोज़न सिमुलेशन हाइटमैप रिज़ॉल्यूशन (1-मीटर ग्रिड) पर चलता है। असली टेरेन में सेंटीमीटर पैमाने पर बारीक इरोज़न पैटर्न (rills, gullies, weathering cracks) होते हैं।

Grenier et al. (2024, CGF) रियल टाइम में टेरेन माइक्रो-डिटेल जोड़ने के लिए phasor noise इस्तेमाल करते हैं। Phasor noise एक stochastic phase field को periodic functions में फीड करके structured पैटर्न synthesize करता है। टेरेन पर लागू, यह spatially varying इरोज़न पैटर्न बनाता है जो:

• संकरे rills को scales के पार बड़े gullies में cascade करते हैं
• टेरेन ढलान के साथ अपने आप align होते हैं (इरोज़न पैटर्न fall line का पीछा करते हैं)
• 32x तक amplification हासिल करते हैं (हाइटमैप रिज़ॉल्यूशन के 32x पर detail जोड़ते हुए)
• पूरी तरह एक fragment shader में इंटरैक्टिव frame rates पर चलते हैं

एक ब्राउज़र दुनिया के लिए, phasor noise टेरेन shader में एक detail layer के रूप में चलता है। हाइटमैप बड़े पैमाने का आकार देता है। Phasor noise fragment shader में ज्यामिति की जटिलता बढ़ाए बिना भरोसेमंद माइक्रो-इरोज़न जोड़ता है। पैरामीटर (pattern frequency, amplitude, orientation) प्रति biome अलग हो सकते हैं: खुली चट्टान पर गहरे rills, रेत के टीलों पर हल्की लहरें, सूखी मिट्टी पर खुरदरी छाल जैसी texture।

टेरेन के लिए Virtual Texturing

बड़े पैमाने पर, टेरेन texture atlas बेढंगा हो जाता है। 1 texel प्रति सेंटीमीटर पर एक 4 km x 4 km दुनिया को 400,000 x 400,000 pixel texture चाहिए। साफ तौर पर असंभव।

Virtual texturing (इसे megatexture भी कहते हैं, id Software के Rage से) टेरेन texture को एक paged structure के रूप में मानकर इसे हल करता है। पूरी texture वैचारिक रूप से मौजूद है लेकिन सिर्फ स्क्रीन पर दिखने वाली tiles GPU memory में लोड होती हैं।

पाइपलाइन:

1. Feedback pass: टेरेन को एक shader के साथ रेंडर करें जो आउटपुट करता है कि हर pixel को कौन सी texture tile चाहिए (tile ID और mip level)। इसे CPU में वापस पढ़ें (या एक compute shader से प्रोसेस करें)।
2. Tile loading: अनुरोधित tiles को CDN से लोड करें या splat मैप डेटा से प्रोसीजरल रूप से जेनरेट करें।
3. Indirection texture: एक छोटी texture virtual tile coordinates को एक texture atlas में physical tile coordinates पर map करती है।
4. Render pass: टेरेन shader सही physical tile ढूंढने के लिए indirection texture देखता है, फिर atlas से material texture sample करता है।

WebGPU के compute shaders feedback analysis और page table management पूरी तरह GPU पर संभाल सकते हैं। CPU सिर्फ tile I/O मैनेज करता है।

नतीजा: texture memory विस्फोट के बिना किसी भी रिज़ॉल्यूशन पर unique texturing वाला टेरेन। कैमरा से दूर की tiles low resolution पर लोड होती हैं। पास की tiles high resolution पर लोड होती हैं। कुल memory उपयोग एक fixed बजट के अंदर रहता है (आमतौर पर 128-256 MB texture atlas)।

Dynamic टेरेन इफेक्ट

Puddles और Wetness

बारिश सिर्फ गिरती नहीं। यह जमा होती है। गड्ढों में, यह puddles बनाती है। सतहों पर, यह एक गीली चमक बनाती है। खड़ी ढलानों पर, यह बह जाती है। इसे सिमुलेट करना मौसम को टेरेन से जुड़ा हुआ महसूस कराता है, न कि पूरी तरह विज़ुअल overlay।

shader-आधारित तरीका fluid dynamics सिमुलेट नहीं करता। यह यह तय करने के लिए टेरेन हाइटमैप इस्तेमाल करता है कि पानी कहां जमा होता है:

float concavity = heightCenter * 4.0 - heightLeft - heightRight - heightUp - heightDown;
float puddleDepth = max(0.0, concavity * rainIntensity - evaporationRate * timeSinceRain);
float wetness = smoothstep(0.0, 0.02, puddleDepth);

vec3 wetColor = baseColor * 0.7;
float wetRoughness = baseRoughness * 0.3;
vec3 finalColor = mix(baseColor, wetColor, wetness);
float finalRoughness = mix(baseRoughness, wetRoughness, wetness);

Concave इलाके (हाइटमैप का negative Laplacian) पानी इकट्ठा करते हैं। concavity जितनी गहरी, puddle उतना बड़ा। गीली सतहें गहरी होती हैं और ज्यादा reflective बनती हैं (कम roughness)। बारिश रुकने के बाद असर समय के साथ fade होता है।

पूरे puddle reflections के लिए, puddle सतह पर एक planar reflection pass जोड़ें। या screen-space reflections (SSR) इस्तेमाल करें जो सस्ते हैं और Three.js और Babylon.js दोनों के post-processing stacks में पहले से उपलब्ध हैं।

Puddle सतहों पर बारिश की बूंदें एक feedback texture में एक साधारण 2D wave equation इस्तेमाल करती हैं (Saurel, 2026, Blog)। हर बारिश की बूंद एक ripple बनाती है जो बाहर की ओर फैलती है और घटती है। wave texture puddle normal map को modulate करती है, और 60fps पर भरोसेमंद ripple पैटर्न बनाती है।

Footprints और Terrain Deformation

जब एक प्लेयर नरम टेरेन (रेत, बर्फ, मिट्टी) पर चलता है, footprints फिजिकल मौजूदगी का एहसास बढ़ाते हैं। तकनीक: प्रति chunk एक छोटी deformation texture (64x64 pixels = 4 KB) रखें जो हाइट offsets स्टोर करती है। जब एक कैरेक्टर नरम टेरेन पर कदम रखता है, deformation texture में एक footprint आकार stamp करें।

टेरेन vertex shader deformation texture पढ़ता है और हाइट से offset घटाता है। टेरेन fragment shader footprint इलाके को गहरा करता है (दबी हुई मिट्टी गहरी होती है) और roughness बढ़ाता है (अस्त-व्यस्त सतह)।

Footprints deformation texture को धीरे-धीरे शून्य करके समय के साथ fade होते हैं (बर्फ भर जाती है, बारिश मिट्टी के निशान धो देती है)। fade दर मौसम पर निर्भर करती है: बारिश में तेज, सूखे में धीमी।

एक मल्टीप्लेयर दुनिया के लिए, footprint डेटा ephemeral और local है। हर क्लाइंट दिखने वाले प्लेयर के लिए footprints जेनरेट करता है। deformation texture को clients के बीच sync करने की जरूरत नहीं (हर कोई अपने version के transient footprints देखता है)। यह हर कदम broadcast करने की networking कॉस्ट से बचाता है।

Procedural Sky और Day/Night Cycle

आसमान किसी भी ओपन वर्ल्ड में सबसे बड़ी दिखने वाली सतह है। यह पूरे टेरेन का mood तय करता है।

Three.js में एक complete sky system है जिसमें procedural sun/moon, day/night cycle, बादल, तारे और lens flares शामिल हैं। built-in Three.js Sky example (जो WebGPU में भी उपलब्ध है) Preetham का एनालिटिकल sky model लागू करता है।

ज्यादा फिजिकली सटीक नतीजों के लिए, webgpu-sky-atmosphere Hillaire के atmosphere model को एक WebGPU post-process के रूप में लागू करता है। यह multiple scattering phase functions सपोर्ट करता है और first principles से सही aerial perspective (दूर का टेरेन ज्यादा धुंधला दिखता है), sun/sunset रंग, और sky gradients बनाता है।

TerrainView7 precomputed atmospheric scattering के साथ WebGPU में full-scale planet rendering दिखाता है, और साबित करता है कि फिजिकली सटीक atmosphere rendering एक ब्राउज़र में चलती है।

एक क्रिएटर दुनिया के लिए, sky पैरामीटर (sun position, बादल कवरेज, धुंध density) सभी clients में सर्वर की world clock से synchronize होते हैं। sky shader हर client पर local चलता है, और सभी प्लेयर में एकसमान lighting बनाता है।

टेरेन Lighting: Indirect Illumination

सीधी धूप shadow maps से संभाली जाती है। लेकिन छाया में टेरेन का रंग और चमक (ambient/indirect light) विज़ुअल क्वालिटी के लिए उतना ही जरूरी है। पूरी तरह काली छायाएं गलत दिखती हैं। छायाओं को sky रंग से tint होना चाहिए (साफ दिन पर नीली, बादल वाले दिन पर ग्रे)।

एक ब्राउज़र दुनिया के लिए, व्यावहारिक तरीका:

Screen-space indirect lighting visibility bitmask के साथ (Jimenez et al., 2023, Paper) प्रति pixel 32 directional visibility sectors ट्रैक करके मानक SSAO में सुधार करता है। यह सिर्फ यह नहीं पकड़ता कि एक पॉइंट कितना occluded है, बल्कि occlusion की दिशा भी। पतली सतहें सही ढंग से दूसरी तरफ से रोशनी आने देती हैं। नतीजा एक ऐसा indirect illumination है जो global illumination infrastructure के बिना पास की ज्यामिति पर प्रतिक्रिया करता है।

कॉस्ट SSAO के बराबर है (1-2ms)। विज़ुअल सुधार बड़ा है: canyons में टेरेन canyon की दीवारों से bounce light उठाता है। ओवरहैंग के नीचे ground reflection से रोशन होते हैं। यह असर sky shader के atmospheric scattering के साथ मिलकर फिजिकली प्रेरित ambient lighting बनाता है।

टेरेन Physics Integration

Rapier Heightfield Colliders

Rapier का WASM physics engine टेरेन के लिए optimized native heightfield colliders देता है। एक टेरेन collider बनाना सीधा है:

const heights = new Float32Array(65 * 65);
// Fill with heightmap data...
const groundCollider = RAPIER.ColliderDesc.heightfield(
  64, 64, heights, new RAPIER.Vector3(64.0, 100.0, 64.0)
);
world.createCollider(groundCollider);

heightfield collider कुशल broadphase queries के लिए structured grid इस्तेमाल करता है। एक heightfield के खिलाफ raycasting एक triangle mesh के O(n) के बजाय O(log n) है। एक 65x65 chunk के लिए, collision queries microseconds में हल होती हैं।

वॉल्यूमेट्रिक टेरेन (SDF ओवरले) वाले chunks के लिए, marching cubes आउटपुट से एक triangle mesh जेनरेट करें और एक trimesh collider इस्तेमाल करें। यह heightfield collider से ज्यादा महंगा है लेकिन मनचाही ज्यामिति संभालता है। सिर्फ प्लेयर के सबसे नज़दीकी 3-5 chunks के लिए trimesh colliders जेनरेट करें। दूर के chunks को physics नहीं चाहिए।

परफॉर्मेंस: एक 65x65 chunk के लिए Rapier का heightfield collider character controller queries के लिए प्रति physics step लगभग 0.1ms जोड़ता है। heightfield colliders वाले 5 active chunks: 0.5ms। एक वॉल्यूमेट्रिक chunk के लिए एक trimesh collider: 0.2-0.5ms। कुल टेरेन physics बजट: 1ms से कम, पूरी दुनिया के लिए 2-3ms physics बजट के अंदर अच्छे से।

Terrain-Aware Character Controller

character controller को टेरेन गुणों पर प्रतिक्रिया देनी होगी:

• Slope limiting: कैरेक्टर 45 डिग्री तक की ढलानों पर चल सकता है। ज्यादा खड़ी ढलानें फिसलन पैदा करती हैं। यह कैरेक्टर की पोज़ीशन पर टेरेन normal इस्तेमाल करता है (हाइटमैप gradient से सस्ते में compute होता है)।
• Surface material response: चट्टान पर चलना रेत या मिट्टी पर चलने से अलग footstep आवाज और movement speed पैदा करता है। टेरेन का splat मैप किसी भी पॉइंट पर सतह का मटेरियल देता है।
• Step climbing: कैरेक्टर 0.5 मीटर तक के कगारों पर चढ़ सकता है। Rapier का KinematicCharacterController इसे configurable step height के साथ अपने आप संभालता है।

ब्राउज़र में Interactive Terrain Editing

एक क्रिएटर दुनिया के लिए, टेरेन सिर्फ जेनरेट नहीं होता। इसे प्लेयर sculpt, modify और reshape करते हैं। editing टूल को responsive (तुरंत विज़ुअल feedback) और networked (बाकी प्लेयर सेकंडों में बदलाव देखें) होना चाहिए।

WebGPU SDF Editor

Reinder Nijhoff का WebGPU SDF Editor दिखाता है कि full-featured SDF modeling आज ब्राउज़र में काम करती है। editor सपोर्ट करता है:

• छह primitive आकार (sphere, box, cone, cylinder, capsule, torus) position, rotation और scale के साथ
• Boolean ऑपरेशन (union, subtraction, intersection) smooth blending और configurable blend radii के साथ
• Hierarchical scene graphs groups और nested ऑपरेशन के साथ
• Real-time rendering कई GPU compute shader stages, 16,384 grid cells में octree-आधारित space partitioning, और marching cubes या surface nets के जरिए surface extraction इस्तेमाल करते हुए
• Temporal anti-aliasing और ambient occlusion shadow maps के जरिए

हर primitive एक ही GPU buffer में 28 floats (112 bytes) के रूप में स्टोर होता है। यह compact रिप्रेजेंटेशन मतलब है कि एक जटिल टेरेन एडिट (दर्जनों SDF primitives जो एक गुफा प्रवेश, एक मेहराब, या एक carved चट्टान की सतह तय करते हैं) 5 KB से कम का होता है और बाकी प्लेयर के साथ तुरंत sync होता है।

एक क्रिएटर दुनिया के लिए, SDF editing workflow ऐसा दिखता है:

1. क्रिएटर एक sculpting टूल चुनता है (sphere जोड़ो, box घटाओ, smooth blend)
2. SDF primitive रखने और साइज़ करने के लिए दुनिया में click/drag करता है
3. क्लाइंट तुरंत local मेश अपडेट करने के लिए modified SDF पर marching cubes चलाता है (<16ms में feedback)
4. SDF एडिट (primitive type + transform + blend mode, ~100 bytes) सर्वर को भेजा जाता है
5. सर्वर एडिट validate करता है (क्रिएटर के plot के अंदर, protected इलाकों से intersect नहीं करता) और पास के प्लेयर को broadcast करता है
6. बाकी प्लेयर के clients SDF एडिट लागू करते हैं और अपनी local मेश फिर जेनरेट करते हैं

एक एडिट के बाकी लोगों को दिखने का कुल round-trip: नेटवर्क latency के हिसाब से 100-300ms। क्रिएटर अपना एडिट तुरंत देखता है क्योंकि यह सर्वर पुष्टि से पहले local लागू होता है।

Brush-Based Heightmap Editing

हाइटमैप लेयर के लिए (टेरेन का 90% जिसे वॉल्यूमेट्रिक फीचर नहीं चाहिए), एक सरल editing model काम करता है। क्रिएटर एक ब्रश से हाइट बदलाव पेंट करता है:

• Raise/lower: falloff के साथ एक radius में हाइट जोड़ें या घटाएं
• Smooth: एक radius में हाइट औसत करें, sharp फीचर हटाते हुए
• Flatten: एक radius में सभी हाइट को एक target वैल्यू पर सेट करें
• Erosion brush: ब्रश radius में local hydraulic इरोज़न के कुछ steps लगाएं

हाइटमैप एडिट एक delta है: हाइट बदलाव का एक छोटा patch जो बेस टेरेन के ऊपर overlay होता है। delta patch छोटा है (16-bit हाइट offsets का एक 32x32 ग्रिड = 2 KB) और बाकी प्लेयर के साथ एक ही message के रूप में sync होता है। प्रति chunk कई delta patches जमा होते हैं और समय-समय पर सर्वर-साइड chunk के persistent हाइटमैप में merge होते हैं।

Collaborative Editing बाधाएं

जब कई क्रिएटर एक ही chunk एक साथ एडिट करते हैं, सिस्टम को नियम चाहिए:

• Spatial locking: एक दिए गए 8x8 मीटर sub-region को एक बार में सिर्फ एक क्रिएटर एडिट कर सकता है। lock तब हासिल होता है जब क्रिएटर एक edit stroke शुरू करता है और तब छूटता है जब वे ब्रश उठाते हैं। 10 सेकंड की निष्क्रियता के बाद locks timeout हो जाते हैं।
• Non-overlapping edits: अगर दो क्रिएटर एक ही chunk के अलग हिस्से एडिट करते हैं, दोनों एडिट बिना टकराव के लागू होते हैं (वे अलग हाइटमैप cells या SDF regions बदलते हैं)।
• Overlapping edits: अगर दो क्रिएटर एक ही जगह एडिट करते हैं, सर्वर एडिट को आगमन क्रम में serialize करता है। reconciliation के बाद दोनों clients वही अंतिम नतीजा देखते हैं।

यह placed objects के लिए इस्तेमाल किए जाने वाले पूरे CRDT तरीके से सरल है क्योंकि टेरेन एडिट एक निरंतर field (हाइट, SDF distances) पर additive ऑपरेशन हैं, न कि अलग object state।

WebGPU में Nanite-Style Virtual Geometry

Unreal Engine 5 का Nanite build time पर एक cluster DAG (directed acyclic graph) बनाकर और runtime पर screen-space error के आधार पर per-cluster सही LOD चुनकर अरबों त्रिभुज रेंडर करता है। पूरी पाइपलाइन GPU पर चलती है। इस तरीके को WebGPU में port किया गया है।

Nanite WebGPU

Nanite WebGPU by Scthe (1.1k+ GitHub stars) Nanite के core आर्किटेक्चर का एक पूरा ब्राउज़र इम्प्लीमेंटेशन है:

• Meshlet LOD hierarchy meshoptimizer के cluster generation का इस्तेमाल करके offline बनाई गई
• Software rasterizer WGSL compute shaders में लागू (WebGPU की उन बाधाओं के अंदर काम करते हुए जहां hardware rasterization per-cluster draws कुशलता से नहीं कर सकती)
• Per-instance और per-meshlet culling frustum और occlusion tests इस्तेमाल करते हुए
• Billboard impostors बेहद दूर के objects के लिए
• Texture और per-vertex normal सपोर्ट

पाइपलाइन: meshes को ~128 त्रिभुजों के clusters में बांटा जाता है। पड़ोसी clusters को group किया जाता है, और हर group को simplify किया जाता है (meshoptimizer इस्तेमाल करते हुए) जबकि shared boundaries बचाई जाती हैं। यह तब तक recurse करता है जब तक पूरी मेश एक ही cluster में collapse न हो जाए। runtime पर, एक compute shader DAG पर चलता है और per-group सबसे मोटा cluster चुनता है जो मौजूदा screen resolution पर 1 pixel से कम error पैदा करता है।

THREE-Nanite एक उभरता हुआ Three.js इम्प्लीमेंटेशन है जो integrated graphics hardware पर 20-40fps हासिल करता है जबकि लाखों त्रिभुज संभालता है। यह दिखाता है कि Nanite-style rendering low-end ब्राउज़र hardware पर भी चलने लायक है।

meshoptimizer: LOD पाइपलाइन की नींव

meshoptimizer (Arseny Kapoulkine द्वारा) ज्यादातर ब्राउज़र-compatible LOD पाइपलाइन के पीछे की library है। Version 1.0 (2025) देता है:

• Mesh simplification error metrics के साथ (आकार कितना बदला, LOD selection के लिए इस्तेमाल)
• Cluster generation Nanite-style meshlet hierarchies के लिए
• Vertex cache optimization GPU-friendly triangle ordering के लिए
• Overdraw optimization pixel shader कॉस्ट घटाने के लिए
• Vertex quantization और compression छोटे downloads के लिए

meshoptimizer 1.0 (दिसंबर 2025 में रिलीज़) एक नया single-header clusterlod.h शिप करता है जो Nanite-style continuous LOD सीधे लागू करता है। यह clusters की एक hierarchy बनाता है जो क्रमिक रूप से group और simplify होती हैं, जो as-is या एक custom पाइपलाइन के लिए reference के रूप में इस्तेमाल हो सकती है। यह वही cluster-DAG primitive है जो टेरेन पाइपलाइन को SDF/marching-cubes मेश LOD के लिए चाहिए।

हमारी टेरेन पाइपलाइन के लिए, meshoptimizer SDF टेरेन के marching cubes आउटपुट को LOD hierarchies वाली optimized, clustered meshes में प्रोसेस करता है। offline processing सर्वर-साइड चलती है। ब्राउज़र pre-clustered meshes पाता है और runtime पर GPU-ड्रिवन LOD selection करता है।

LOD generation के लिए meshoptimizer और runtime selection के लिए WebGPU compute का मेल ब्राउज़र टेरेन को Nanite जैसा ही architectural पैटर्न देता है, web बाधाओं के लिए ढाला हुआ।

Terrain-Aware Level Design

टेरेन सिर्फ एक सतह नहीं है जिस पर चलना हो। इसका आकार प्लेयर की गति को निर्देशित करता है, ध्यान directs करता है, और अन्वेषण का भावनात्मक rhythm बनाता है। सबसे अच्छी ओपन वर्ल्ड टेरेन को एक डिज़ाइन टूल के रूप में इस्तेमाल करती हैं।

Sightlines और Landmarks

Level Design Book का wayfinding chapter बताता है कि कैसे टेरेन एलिवेशन नियंत्रित करता है कि प्लेयर क्या देखते हैं और कहां जाते हैं। एक रिज उसके पीछे की चीज़ छिपाती है, और जिज्ञासा पैदा करती है। एक घाटी गति को अपने सबसे नीचे पॉइंट की ओर funnel करती है। दूर से दिखने वाला एक ऊंचा landmark (टावर, पर्वत शिखर, असामान्य पेड़) प्लेयर को चलने के लिए एक लक्ष्य देता है।

एक क्रिएटर दुनिया के लिए, इसका मतलब है कि टेरेन जेनरेशन को प्राकृतिक wayfinding फीचर बनाने चाहिए। रिज लाइन को sightlines तोड़नी चाहिए, और "reveal moments" बनाने चाहिए जब एक प्लेयर एक पहाड़ी की चोटी पर पहुंचता है और एक नया इलाका देखता है। घाटियों को दिलचस्प जगहों की ओर converge करना चाहिए। ऊंचे पॉइंट वहां मौजूद होने चाहिए जहां क्रिएटर दूर से दिखने वाले landmarks रख सकें।

Curiosity-Driven Exploration

Purdue University से रिसर्च (Paper) चार spatial exploration triggers पहचानती है:

1. चरम पॉइंट तक पहुंचना (सबसे ऊंची चोटी, सबसे दूर का किनारा, सबसे गहरी गुफा)। टेरेन में साफ चरम होने चाहिए जो वहां पहुंचने पर इनाम दें।
2. विज़ुअल बाधाएं हल करना (उस चट्टान के पीछे क्या है? उस गुफा के अंदर?)। ऐसा टेरेन जो दृश्य रोकता है, छिपी चीज़ ढूंढने के लिए गति को प्रेरित करता है।
3. जगह से बाहर के objects (जंगल में एक संरचना, अंधेरे में एक रोशनी)। प्राकृतिक टेरेन के खिलाफ क्रिएटर-रखे objects एक contrast बनाते हैं जो ध्यान खींचता है।
4. Spatial connections समझना (यह घाटी उस तट से कैसे जुड़ती है?)। ऐसा टेरेन जो पठनीय भूगोल बनाता है, map-reading और route-planning को प्रोत्साहित करता है।

PlotMap: AI-Assisted POI Placement

PlotMap (arXiv:2309.15242) narrative requirements (इस quest को एक नदी के पास एक गांव चाहिए, उस quest को एक पहाड़ी की चोटी पर एक खंडहर चाहिए) लेकर और spatial constraints संतुष्ट करने वाली टेरेन जगहें ढूंढकर point-of-interest layout को automate करता है। एक क्रिएटर दुनिया के लिए, एक समान सिस्टम टेरेन गुणों के आधार पर सुझा सकता है कि संरचनाएं कहां रखें: "इस पहाड़ी की चोटी पर एक watchtower के लिए अच्छी sightlines हैं," "यह सुरक्षित घाटी एक गांव के लिए उपयुक्त होगी।"

बहता हुआ पानी और Waterfalls

नदियां और waterfalls ऐसे टेरेन फीचर हैं जो विज़ुअल आकर्षण को ambient sound और gameplay affordance (पानी एक बाधा, एक संसाधन, या एक रास्ते के रूप में) के साथ मिलाते हैं।

River Rendering

ओपन वर्ल्ड में नदियां आमतौर पर textured strips के रूप में रेंडर होती हैं जो टेरेन सतह का पीछा करती हैं। strip मेश river spline (control points के रूप में स्टोर) से जेनरेट होती है और टेरेन हाइटमैप पर project होती है। river shader लगाता है:

• Flow-aligned UVs जो नदी की दिशा में scroll करते हैं, बहते पानी का रूप बनाते हुए
• किनारों पर Foam जहां नदी bank से मिलती है (depth-आधारित, shoreline foam जैसा)
• Speed variation channel की चौड़ाई के आधार पर (संकरे हिस्से तेज बहते हैं, चौड़े हिस्से धीमे)
• depth-आधारित रंग के साथ Transparency (उथला साफ है, गहरा गहरे रंग का)

एक ब्राउज़र दुनिया के लिए, river डेटा compact है: एक spline (प्रति river segment 20-50 control points, ~400 bytes) और चौड़ाई और flow speed पैरामीटर। क्लाइंट spline को अपनी टेरेन सतह पर project करके river मेश local जेनरेट करता है।

Waterfall Rendering

जहां एक नदी एक चट्टान की सतह से गिरती है, एक waterfall particle system समतल river सतह की जगह लेता है। रियल-टाइम water simulation रिसर्च से hybrid तरीका (EG): वे regions जो एक height field से रिप्रेजेंट नहीं हो सकते (waterfalls, splashes) spray, splash और foam particles में बदल जाते हैं जो fluid simulation के साथ mass और momentum exchange करते हैं।

एक ब्राउज़र दुनिया के लिए, waterfalls सरल हैं: पता लगाएं कि river spline कहां एक टेरेन height discontinuity पार करती है, उस पॉइंट पर downward velocity के साथ एक particle system spawn करें, और आधार पर एक foam splash जोड़ें। particles scrolling alpha textures वाले GPU-instanced quads हैं। प्रति waterfall 500 particles, एक draw call। गिरते पानी की आवाज distance attenuation के साथ Web Audio API इस्तेमाल करती है।

दूर के टेरेन फीचर के लिए Impostors

पेड़, चट्टानें, इमारतें और बाकी टेरेन फीचर दूरी पर छोटे हो जाते हैं। उन्हें पूरी 3D meshes के रूप में रेंडर करना GPU cycles बर्बाद करता है। Impostors दूर के objects की जगह pre-rendered समतल images रखते हैं जो कैमरा की ओर face करती हैं।

Octahedral Impostor Atlases

एक octahedral impostor एक 3D object के रूप को कई देखने के कोणों से पकड़ता है और उन्हें एक texture atlas में स्टोर करता है। runtime पर, shader मौजूदा view direction के आधार पर atlas sample करता है, और दो सबसे नज़दीकी पकड़े गए कोणों के बीच interpolate करता है।

एक hemi-octahedral atlas (सिर्फ ऊपरी hemisphere से views, क्योंकि आप शायद ही पेड़ों को नीचे से देखते हैं) उसी texture size के साथ एक पूरे octahedral atlas की दोगुनी angular resolution देता है। Unity का impostor system रिपोर्ट करता है कि 1,600 tree instances को असली meshes (हर एक 140K त्रिभुज) से impostors में स्विच करने पर frame time 111ms से गिरकर 5.78ms हो जाता है।

एक ब्राउज़र दुनिया के लिए, impostor पाइपलाइन:

1. सर्वर-साइड: हर asset को 16-32 देखने के कोणों से रेंडर करें, color, normal और depth पकड़ते हुए
2. एक atlas texture में पैक करें (प्रति asset एक atlas, ~256x256 pixels, KTX2 के रूप में <100 KB)
3. runtime पर: impostor distance (आमतौर पर 100-200m) से परे के instances atlas sample करते हुए billboards के रूप में रेंडर होते हैं
4. स्विच छिपाने के लिए एक 20m ट्रांज़िशन zone पर मेश और impostor के बीच crossfade करें

Billboard Splatting (BBSplat)

Billboard Splatting (2024, arXiv:2411.08508) learnable textured planar primitives इस्तेमाल करके इसे आगे ले जाता है। pre-rendered views के बजाय, BBSplat किसी भी कोण से 3D object को सबसे अच्छे से दर्शाने के लिए billboard positions और textures को optimize करता है। यह 3D Gaussian Splatting की तुलना में 17x तक compression हासिल करता है जबकि view-dependent रूप बनाए रखता है। एक ब्राउज़र दुनिया में दूर के टेरेन फीचर के लिए, BBSplat angular coverage सुधारते हुए per-asset impostor storage घटा सकता है।

Professional टेरेन टूल और वे क्या सिखाते हैं

शून्य से एक टेरेन पाइपलाइन बनाने से पहले, यह समझने लायक है कि professional offline टूल क्या करते हैं। ये टूल दशकों की टेरेन जेनरेशन रिसर्च को production workflows में distill करते हैं।

Gaea (QuadSpinner) GPU-accelerated है और बदलावों पर लगभग तुरंत feedback देता है। यह प्रति साइड 2 मिलियन pixels तक tiled builds, automatic LOD mesh export, और एक node-आधारित graph सपोर्ट करता है जहां हर node एक फिजिकल प्रोसेस है (इरोज़न, sedimentation, uplift, thermal weathering)। Gaea के इरोज़न nodes ऐसा टेरेन बनाते हैं जो हाथ से sculpt किया हुआ दिखता है क्योंकि वे generic noise के बजाय खास फिजिकल प्रोसेस मॉडल करते हैं। मुख्य अंतर्दृष्टि: Gaea एक ही इरोज़न एल्गोरिदम इस्तेमाल नहीं करता। यह fluvial इरोज़न (नदी carving), thermal इरोज़न (चट्टान crumbling), coastal इरोज़न (wave action), और wind इरोज़न (रेत के टीले बनना) के लिए अलग nodes देता है। उन्हें एक graph में मिलाने से एक खास जलवायु के भूगर्भीय चरित्र वाला टेरेन बनता है।

World Machine टेरेन macro-structure पर ध्यान देते हुए एक समान graph तरीका लेता है। इसका "layout generator" आर्टिस्ट को टेरेन फीचर का मोटा आकार स्केच करने देता है (यहां पर्वत, वहां घाटी, इस किनारे तटरेखा) और सिस्टम फिजिकली संभव detail भर देता है। यह बिल्कुल वही क्रिएटर workflow है जो हम चाहते हैं: इरादा स्केच करो, भूविज्ञान पाओ।

World Creator editing के दौरान real-time preview और built-in river generation के साथ खुद को अलग करता है, जो टेरेन का विश्लेषण करती है और drainage analysis के आधार पर अपने आप flow paths calculate करती है।

इन टूल से हम क्या लेते हैं: फिजिकल प्रोसेस को मिलाने का node-graph तरीका किसी भी एक एल्गोरिदम से ज्यादा असरदार है। हमारी सर्वर-साइड जेनरेशन पाइपलाइन को chaining सपोर्ट करनी चाहिए: noise base > tectonic uplift > hydraulic इरोज़न > thermal weathering > coastal इरोज़न > वनस्पति। क्रिएटर हर stage पर पैरामीटर नियंत्रित करते हैं। पाइपलाइन सर्वर-साइड सेकंडों में चलती है और हाइटमैप, splat maps और वनस्पति density maps बनाती है।

SoilMachine: Open-Source Geomorphology

SoilMachine एक open-source modular geomorphology सिमुलेटर है जो कई इरोज़न सिस्टम (hydraulic, thermal, wind) को sediment transport और deposition के साथ couple करता है। GPU compute के साथ C++ में बना, यह multi-process इरोज़न तरीके का एक reference इम्प्लीमेंटेशन देता है जो professional टूल इस्तेमाल करते हैं।

संबंधित soillib (C++20, MIT license) अंतर्निहित geomorphology simulation primitives को एक reusable library के रूप में देता है। और hydro-gen OpenGL compute shaders में real-time पैरामीटर adjustment के साथ grid-आधारित (shallow water) और particle-आधारित (raindrop) hydraulic इरोज़न दोनों लागू करता है।

ये open-source टूल हमारी सर्वर-साइड जेनरेशन पाइपलाइन के लिए ढाले जा सकते हैं। compute shader इम्प्लीमेंटेशन सीधे WebGPU में translate होते हैं अगर हम कभी real-time क्रिएटर feedback के लिए ब्राउज़र में इरोज़न चलाना चाहें।

Multi-Layer Terrain Materials

असली टेरेन एक ही सतह नहीं है। यह लेयर है: नीचे bedrock, ऊपर मिट्टी, सतहों पर जमा होती बर्फ या रेत। Dynamic layering मौसमों, मौसम और क्रिएटर actions के साथ टेरेन का विज़ुअल चरित्र बदलती है।

Layered Heightfield Representation

एक ही हाइटमैप के बजाय, प्रति grid cell कई height layers इस्तेमाल करें:

Cell {
  bedrock_height: f16,    // permanent rock surface
  soil_height: f16,       // accumulated soil/sediment above bedrock
  snow_height: f16,       // dynamic snow accumulation
  water_height: f16       // standing water depth
}

कुल: प्रति cell 8 bytes (एक ही हाइटमैप के लिए 2 bytes बनाम)। एक 65x65 chunk के लिए, यह compression से पहले 34 KB है। फिर भी compact।

विज़ुअल सतह bedrock + soil + snow है। टेरेन shader सभी layers पढ़ता है और तदनुसार मटेरियल blend करता है: जहां मिट्टी पतली है, चट्टान दिखती है। जहां बर्फ जमा है, सतह सफेद है। जहां पानी बैठा है, आपको puddles या झीलें मिलती हैं।

Dynamic Accumulation

बर्फबारी के दौरान बर्फ समतल, ऊपर की ओर मुंह वाली सतहों पर जमा होती है। accumulation दर सतह के normal (खड़ी ढलानें बर्फ नहीं रोकतीं), तापमान (altitude-निर्भर), और shelter (ओवरहैंग के नीचे के इलाके साफ रहते हैं) पर निर्भर करती है। एक compute shader pass प्रति weather tick (हर कुछ सेकंड) snow layer अपडेट करता है।

रेत accumulation wind-driven deposition के साथ इसी तरह काम करती है। हवा खुली सतहों से particles ले जाती है और बाधाओं के पीछे और सुरक्षित इलाकों में जमा करती है।

एक क्रिएटर दुनिया के लिए, dynamic accumulation मतलब है कि टेरेन अलग मौसम में अलग दिखता है। एक बर्फानी तूफान के दौरान बर्फ दुनिया को ढक लेती है और साफ मौसम में पिघल जाती है। बारिश गड्ढों को पानी से भरती है। यह दुनिया को क्रिएटर के कुछ किए बिना responsive महसूस कराता है।

Multi-Layered इरोज़न

2024 का पेपर "3D Real-Time Hydraulic Erosion Simulation using Multi-Layered Heightmaps" (EG) इरोज़न को layers के पार काम करने के लिए बढ़ाता है। पानी bedrock से तेज मिट्टी को erode करता है। Sediment एक नई soil layer के रूप में जमा होता है। सिमुलेशन layer integrity बनाए रखता है (bedrock मिट्टी के नीचे रहता है) जबकि ओवरहैंग (जहां bedrock नीचे eroded मिट्टी के ऊपर लटकता है) जैसे जटिल फीचर सक्षम करता है।

परफॉर्मेंस: 2048x2048 रिज़ॉल्यूशन पर एक RTX 3070 पर प्रति simulation step लगभग 6ms। यह सर्वर-साइड जेनरेशन के लिए काफी तेज है लेकिन per-frame ब्राउज़र simulation के लिए बहुत धीमा। लेयर्ड रिप्रेजेंटेशन स्थिर टेरेन जेनरेशन के लिए काम करता है, और dynamic snow/water accumulation एक सस्ते per-frame shader के रूप में चलता है।

घास, चट्टान और Detail Rendering

लैंडस्केप को टेरेन ज्यामिति और टेक्सचर से ज्यादा चाहिए। इसे ऐसे घास के तिनके चाहिए जो हवा में लहराएं, ढलानों पर बिखरी चट्टानें, और फूल, कंकड़ और गिरी हुई टहनियों जैसे छोटे detail जो पास से देखने पर प्राकृतिक लगें।

GPU-Instanced घास

ब्राउज़र-आधारित घास rendering Three.js में अच्छी तरह आजमाई हुई है और GPU instancing के जरिए काम करती है। al-ro के grass demo से तरीका InstancedBufferGeometry इस्तेमाल करके एक ही draw call के साथ 100,000 घास के तिनके रेंडर करता है।

हर घास का तिनका एक साधारण quad (4-8 त्रिभुज) है। per-instance attributes position, height, bend direction, color variation और wind phase तय करते हैं। vertex shader:

1. per-instance transform पढ़ता है
2. world position और time से keyed sine waves इस्तेमाल करके wind animation लगाता है
3. wind strength के आधार पर तिनके को मोड़ता है (टिप पर ज्यादा bend, आधार पर कोई नहीं)
4. color gradient लगाता है (subsurface scattering के लिए आधार पर गहरा, टिप पर हल्का)

Codrops का fluffy grass tutorial (2025, Tutorial) एक shell texturing तरीका दिखाता है: ground plane को बढ़ते offsets पर कई बार रेंडर करें, हर layer घनी घास के आयतन का रूप बनाने के लिए एक noise texture sample करते हुए। यह बहुत घनी कवरेज के लिए अलग-अलग blade instancing से सस्ता है लेकिन पास से कम असली।

एक क्रिएटर दुनिया के लिए, घास घनत्व प्रति chunk वनस्पति density map से आता है। GPU render time पर density map से blade positions बिखेरता है। कोई per-blade डेटा स्टोर या स्ट्रीम नहीं होता। density map प्रति chunk एक 32x32 ग्रिड (1 KB) है, और GPU इससे हजारों blade instances जेनरेट करता है।

Procedural Rock और Cliff Detail

चट्टान की सतहों और चट्टानी टेरेन को geometric detail चाहिए जो बेस हाइटमैप या SDF reasonable रिज़ॉल्यूशन पर नहीं दे सकते। दो तरीके एक-दूसरे के पूरक हैं:

GPU mesh shader resurfacing (Raad et al., Eurographics 2025, Paper) render time पर एक मोटे control mesh से procedural ज्यामिति जेनरेट करता है। mesh shader एक बेस टेरेन सतह पढ़ता है और detail ज्यामिति को memory में स्टोर किए बिना displacement, दरारें और protrusions जोड़ता है। यह VRAM उपयोग घटाता है और dynamic LOD सक्षम करता है।

Instanced rock scattering GPU instancing इस्तेमाल करके खड़ी ढलानों और चट्टान के किनारों पर pre-made rock meshes रखता है। एक compute shader टेरेन normal और slope पढ़ता है, और जहां slope एक threshold से ज्यादा हो वहां rock instances बिखेरता है। हर instance एक छोटी मेश (200-500 त्रिभुज) है random rotation और scale के साथ। 10,000 बिखरी चट्टानें instancing के साथ नगण्य rendering कॉस्ट जोड़ती हैं।

सड़कें और रास्ते

क्रिएटर-रखी सड़कों, trails और रास्तों को टेरेन के मुताबिक conform करना और सतह मटेरियल बदलना (घास को मिट्टी या पत्थर से बदलना) चाहिए।

हर बड़े game engine द्वारा इस्तेमाल किया जाने वाला तरीका: रास्ते को एक spline (control points की एक श्रृंखला) के रूप में तय करें। spline को टेरेन सतह पर project करें। एक strip मेश जेनरेट करें जो spline का पीछा करती है और टेरेन से थोड़ा ऊपर बैठती है। strip पर एक road texture लगाएं। टेरेन shader में, एक projected texture या decal इस्तेमाल करके spline की चौड़ाई के अंदर टेरेन मटेरियल को road मटेरियल की ओर blend करें।

एक ब्राउज़र दुनिया के लिए, एक क्रिएटर टेरेन पर एक रास्ता बनाता है। क्लाइंट control points जेनरेट करता है और उन्हें सर्वर को भेजता है (कुछ दर्जन vec3 वैल्यू)। सर्वर spline स्टोर करता है। सभी clients spline को अपनी टेरेन मेश पर project करके road strip local रेंडर करते हैं। road डेटा छोटा है (path spline points, शायद 200 bytes) लेकिन विज़ुअल असर बड़ा है: क्रिएटर builds को जोड़ने वाले रास्ते दुनिया को बसी हुई महसूस कराते हैं।

टेरेन के लिए Shadows

टेरेन shadows readability (टेरेन का आकार समझना) और वातावरण (दिन के समय का mood) के लिए जरूरी हैं। एक ओपन वर्ल्ड में, सूरज पूरे दृश्य टेरेन पर छायाएं डालता है।

Cascaded Shadow Maps (CSM)

CSM view frustum को 3-4 distance ranges (cascades) में बांटता है। हर cascade सूरज के नज़रिए से एक shadow map को अपनी दूरी के लिए उचित रिज़ॉल्यूशन पर रेंडर करता है। पास का cascade: high resolution (पेड़ों और इमारतों के नीचे विस्तृत छायाएं)। दूर का cascade: low resolution (व्यापक पर्वत छायाएं)।

Three.js और Babylon.js दोनों CSM सपोर्ट करते हैं। टेरेन के लिए मुख्य optimization: shadow map में सिर्फ टेरेन रेंडर करें, अलग-अलग घास के तिनके या छोटे detail नहीं। घास टेरेन के shadow map का इस्तेमाल करके self-shadow करती है, अपने खुद के का नहीं।

परफॉर्मेंस बजट: हर एक 1024x1024 पर 3-4 shadow cascades। टेरेन को shadow maps में रेंडर करने की कॉस्ट 0.5-1ms (टेरेन ज्यामिति पहले से GPU memory में है)। टेरेन shader में 4 cascades sample करना 0.2-0.3ms जोड़ता है।

हाइटमैप से Terrain Self-Shadowing

बहुत बड़े टेरेन के लिए जहां CSM महंगा हो जाता है, एक horizon map pre-compute करें: हर टेरेन cell के लिए, 8 compass दिशाओं में अधिकतम elevation angle स्टोर करें। render time पर, यह तय करने के लिए कि एक पॉइंट छाया में है या नहीं, sun angle की horizon map से तुलना करें। Skyrim दूर के टेरेन (CSM range से परे) के लिए टेरेन self-shadows ऐसे ही संभालता है।

horizon map हाइटमैप से सर्वर-साइड compute होता है (कुछ सेकंड की processing) और एक 128x128 per-chunk texture (16 KB compressed) के रूप में स्ट्रीम होता है। विज़ुअल असर बड़ा है: पर्वत घाटियां चरम view distances पर भी असली रूप से गहरी होती हैं।

Streaming के लिए टेरेन डेटा Compression

एक ब्राउज़र दुनिया के लिए नेटवर्क bottleneck है। टेरेन डेटा में बचाया गया हर byte एक तेज load time है।

हाइटमैप Compression

Raw 16-bit हाइटमैप अच्छे से compress होते हैं क्योंकि आस-पास की cells की वैल्यू समान होती हैं। पाइपलाइन:

1. Delta encoding: हर cell और उसकी predicted वैल्यू (पड़ोसियों का औसत) के बीच का अंतर स्टोर करें। Delta वैल्यू छोटी हैं, शून्य के पास clustering करती हैं।
2. Quantization: दूर के chunks के लिए, precision को 16-bit से 12-bit या 8-bit तक घटाएं। 500 मीटर दूर, 8-bit height precision (100m height range पर 0.4m resolution) 16-bit से अलग नहीं दिखती।
3. Entropy coding: delta-encoded stream पर zlib या brotli compression लगाएं। आम compression ratio: 4-8x।

नतीजा: एक 65x65 chunk 16-bit पर 8.4 KB raw से 1-2 KB compressed हो जाता है। 8-bit घटी precision पर: 0.5-1 KB।

Progressive हाइटमैप Streaming

टेरेन को पहले low resolution पर भेजें, फिर refine करें। एक 17x17 हाइटमैप (4m cell spacing वाले 64m chunk के लिए न्यूनतम) 578 bytes raw है, 200 bytes से कम compressed। टेरेन तुरंत दिखता है। फिर 33x33 refinement स्ट्रीम करें (odd-row/column samples जोड़ता है)। फिर 65x65 full resolution। हर स्तर पिछला डेटा बदले बिना detail जोड़ता है।

यह geometry clipmap LOD rings से map होता है: दूर का टेरेन low-resolution version (17x17) इस्तेमाल करता है, mid-range medium (33x33) इस्तेमाल करता है, पास full (65x65) इस्तेमाल करता है। streaming प्राथमिकता rendering LOD से मेल खाती है।

SDF Volume Compression

Sparse SDF वॉल्यूम नाटकीय रूप से compress होते हैं क्योंकि ज्यादातर voxels सतह से दूर हैं (खाली जगह)। विकल्प:

Run-length encoding: समान वैल्यू (खाली voxels) के runs encode करें। आम SDF वॉल्यूम 95%+ खाली होते हैं, इसलिए RLE 10-50x compression हासिल करता है।

Sparse octree: सिर्फ वे octree nodes स्टोर करें जिनमें surface-crossing voxels हों। खाली जगह के कोई nodes नहीं। एक ही cave tunnel वाले एक 64^3 SDF वॉल्यूम में शायद सिर्फ 2,000-5,000 occupied nodes हों (कुल 262,144 voxels बनाम), हर एक 1-2 bytes के रूप में स्टोर।

Entropy-driven progressive compression (2024, HAL) 3D spatial डेटा पर entropy-optimized planes और adaptive quantization के साथ space को recursively partition करके लागू होता है। यह rate-distortion trade-offs के लिए optimized refinements का एक stream बनाता है, जो खासकर नेटवर्क streaming के low bitrates पर फायदेमंद है।

इसे एक साथ रखना: ब्राउज़र टेरेन पाइपलाइन

इस लेख के ऊपर का strategic overview क्विक decision framework और phased build plan देता है। यह सेक्शन सर्वर-साइड जेनरेशन पाइपलाइन और ब्राउज़र rendering पाइपलाइन दोनों के लिए पूरी technical detail देता है।

Generation Pipeline (Server-Side)

जेनरेशन पाइपलाइन फिजिकल प्रोसेस के एक directed graph के रूप में चलती है, जो Gaea और World Machine के node-graph तरीके से प्रेरित है। हर stage पिछली stage का आउटपुट लेकर उसे refine करती है। क्रिएटर हर stage पर पैरामीटर नियंत्रित करते हैं।

एक नई 4x4 km दुनिया 15-90 सेकंड में जेनरेट होती है। क्रिएटर एडिट (sculpting, पैरामीटर बदलाव) सिर्फ प्रभावित chunks के लिए प्रभावित stages फिर चलाते हैं, आमतौर पर 5 सेकंड से कम में पूरे होते हैं।

Rendering Pipeline (Browser)

60fps (प्रति फ्रेम 16.6ms) पर, टेरेन सिस्टम WebGPU पर frame बजट का 21% और WebGL 2 पर 39% इस्तेमाल करता है। बाकी player avatars, क्रिएटर objects, UI, networking और post-processing के लिए उपलब्ध है।

यह एक ब्राउज़र में क्यों काम करता है

पूरी पाइपलाइन तीन ब्राउज़र बाधाओं के इर्द-गिर्द डिज़ाइन की गई है:

Memory (अधिकतम 2-4 GB): 256 MB टेरेन बजट फिट होता है क्योंकि हाइटमैप chunks हर एक 2-8 KB हैं (delta-encoded), SDF वॉल्यूम sparse हैं (प्रति वॉल्यूमेट्रिक chunk 100-500 KB), वनस्पति runtime पर 1 KB density maps से जेनरेट होती है, और टेक्सचर KTX2 compression इस्तेमाल करते हैं (प्रति 1024x1024 150 KB)। किसी भी वक्त, ब्राउज़र में दिखने वाली दुनिया कुल 50-200 MB होती है।

कोई disk access नहीं: सब कुछ नेटवर्क पर स्ट्रीम होता है। Progressive loading मतलब प्लेयर <100ms में टेरेन देखता है (low-res हाइटमैप), <300ms में textured टेरेन, और <3s में full detail। वेलोसिटी के आधार पर pre-fetching सामान्य अन्वेषण के दौरान load times छिपाती है।

GPU बहुत अलग होते हैं: WebGPU रास्ता high-end डेस्कटॉप संभालता है। WebGL 2 fallback बाकी सब संभालता है, mobile सहित। वही chunk डेटा दोनों रास्ते चलाता है। फर्क rendering तकनीक का है, डेटा फॉर्मेट का नहीं। WebGL 2 चलाने वाला एक Chromebook वही दुनिया देखता है जो WebGPU चलाने वाला एक RTX 4090, बस कम detail और छोटी view distance पर।

Research Papers

Terrain Representation और Mesh Generation

"Marching Cubes: A High Resolution 3D Surface Construction Algorithm" -- Lorensen और Cline (SIGGRAPH 1987)। DOI। वॉल्यूमेट्रिक डेटा से triangle meshes निकालने का foundational एल्गोरिदम। 38 साल बाद भी सबसे ज्यादा इस्तेमाल किया जाने वाला isosurface extraction मेथड। GPU-parallel इम्प्लीमेंटेशन WebGPU compute shaders में रियल टाइम में चलते हैं।

"Dual Contouring of Hermite Data" -- Ju, Losasso, Schaefer, Warren (SIGGRAPH 2002)। DOI। ऐसी meshes बनाता है जो sharp फीचर (चट्टान के किनारे, चट्टान के कोने) बचाती हैं जिन्हें marching cubes गोल कर देता है। distance वैल्यू के अलावा surface normals चाहिए।

"Neural Dual Contouring" -- Chen et al. (2022)। arXiv:2202.01999। dual contouring में least-squares vertex placement की जगह एक learned predictor रखता है। जटिल प्राकृतिक फीचर के लिए बेहतर सतह क्वालिटी।

"The Transvoxel Algorithm" -- Lengyel (2009, 2024 में अपडेट)। transvoxel.org। voxel टेरेन के लिए seamless LOD ट्रांज़िशन। 73 transition cell types इस्तेमाल करके रिज़ॉल्यूशन boundaries पर दरारें खत्म करता है। Patent-free, रियल-टाइम एप्लिकेशन के लिए डिज़ाइन किया गया।

Terrain LOD और Rendering

"Geometry Clipmaps: Terrain Rendering Using Nested Regular Grids" -- Losasso और Hoppe (SIGGRAPH 2004)। Paper। concentric LOD rings के साथ constant-cost टेरेन rendering। इंटरैक्टिव rates पर 40 GB टेरेन संभालता है। ज्यादातर ब्राउज़र टेरेन renderers की नींव।

"CDLOD: Hybrid LOD for Terrain Rendering" -- Strugar (2014)। Paper। geometry clipmaps पर quadtree-adaptive सुधार। सिर्फ दूरी के बजाय टेरेन जटिलता के आधार पर रिज़ॉल्यूशन allocate करता है।

"GPU-Driven Rendering Pipelines" -- Ubisoft (SIGGRAPH 2015), Wihlidal और Hoppe। GPU-ड्रिवन तरीके को औपचारिक रूप दिया जहां compute shaders culling, LOD selection, और draw call generation संभालते हैं। हमारी WebGPU टेरेन पाइपलाइन के लिए architectural पैटर्न।

Physical Terrain Generation

"Physically-Based Analytical Erosion for Fast Terrain Generation" -- Cordonnier et al. (2024)। HAL। एनालिटिकल stream power law इरोज़न जो iterative simulation से बचता है। मिलीसेकंड में फिजिकली संभव टेरेन बनाता है।

"Fast Hydraulic Erosion Simulation and Visualization on GPU" -- Mei, Decaudin, Hu (2007)। HAL। shallow-water simulation इस्तेमाल करते हुए GPU-parallel hydraulic इरोज़न। ज्यादातर game engine इरोज़न इम्प्लीमेंटेशन का आधार।

"Arenite: A Physics-Based Sandstone Simulator" -- SIGGRAPH 2025। Project। stress और इरोज़न simulation से मेहराब, hoodoos और alcoves जेनरेट करता मल्टी-फिजिक्स इरोज़न। डेस्कटॉप GPUs पर 5 मिनट से कम में चलता है।

"Efficient Debris-flow Simulation for Steep Terrain Erosion" -- Purdue CGVLAB (2024)। Paper। असली पर्वत टेरेन फीचर बनाता GPU-accelerated debris flow और steep-slope इरोज़न।

"Flexible Terrain Erosion" -- IRIT-STORM (2024)। Springer। particle-आधारित इरोज़न जो एक unified इंटरफेस के साथ heightfields, voxel grids, implicit surfaces और लेयर्ड मटेरियल के पार काम करता है। हाइब्रिड टेरेन रिप्रेजेंटेशन के लिए एक इरोज़न सिस्टम सक्षम करता है।

Terrain Detail और Texturing

"GPU-Friendly Laplacian Texture Blending" -- Wronski (NVIDIA, 2025)। JCGT। बिना precomputation के टेरेन मटेरियल के लिए रियल-टाइम Laplacian pyramid blending। seam artifacts खत्म करते हुए sharp फीचर बचाता है। प्रति fragment कुछ अतिरिक्त texture taps।

"Real-time Terrain Enhancement with Controlled Procedural Patterns" -- Grenier et al. (2024)। CGF। हाइटमैप रिज़ॉल्यूशन के 32x तक phasor noise-आधारित माइक्रो-इरोज़न detail। Slope-aligned पैटर्न पूरी तरह एक fragment shader में चलते हैं।

Adaptive Tessellation

"Concurrent Binary Trees for Large-Scale Game Components" -- Benyoub और Dupuy (Intel, HPG 2024)। Paper। adaptive टेरेन tessellation के लिए GPU-friendly binary tree डेटा संरचना। 0.2ms से कम में ग्रहीय-पैमाने की ज्यामिति रेंडर करती है। चौकोर domains से मनचाहे polygon meshes तक बढ़ाई गई।

Cave और Underground Generation

"PLUME: Procedural Layer Underground Modeling Engine" -- 2024। arXiv:2508.20926। लेयर्ड प्रोसीजरल नियमों का इस्तेमाल करके असली गुफा और lava tube वातावरण जेनरेट करने के लिए open-source फ्रेमवर्क। मूल रूप से अंतरिक्ष अन्वेषण रोबोटिक्स के लिए बना।

Neural Terrain Synthesis

"InfiniteDiffusion: Bridging Learned Fidelity and Procedural Utility for Open-World Terrain Generation" -- Goslin (2025, SIGGRAPH 2026)। arXiv:2512.08309। Laplacian encoding के साथ hierarchical diffusion models इस्तेमाल करते हुए अनंत, seed-consistent टेरेन जेनरेशन। consumer GPUs पर baseline से 9x तेज।

"TerraFusion: Joint Generation of Terrain Geometry and Texture" -- 2025। arXiv:2505.04050। sketch conditioning के साथ एक साथ हाइटमैप और texture synthesis के लिए latent diffusion।

"MESA: Text-Driven Terrain Generation" -- CVPR 2025 Workshop। arXiv:2504.07210। Copernicus remote sensing training data इस्तेमाल करते हुए text-to-terrain।

"Geodiffussr: Generative Terrain Texturing with Elevation Fidelity" -- 2025। arXiv:2511.23029। flow-matching इस्तेमाल करते हुए एलिवेशन डेटा का सम्मान करती text-guided टेरेन texture generation।

"Sketch2Terrain: AI-Driven Real-Time Terrain Sketch Mapping" -- 2025। Project। augmented reality में sketch-to-terrain। मैन्युअल mapping पर 38% efficiency सुधार।

Vegetation और Ecosystem Simulation

"GPU-Based Real-Time Procedural Distribution of Vegetation on Large-Scale Virtual Terrains" -- SBGames 2018। Paper। GPU पर biotic/abiotic factors इस्तेमाल करते हुए quadtree-आधारित वनस्पति scattering।

"Procedural Generation and Rendering of Forests" -- 2022। Paper। असली जंगल वितरण के लिए ecosystem competition simulation के साथ मिलाई गई L-system tree generation।

"Real-Time Procedural Generation with GPU Work Graphs" -- AMD GPUOpen 2024। Paper। 4ms से कम में 79K+ वनस्पति instances जेनरेट करते GPU work graphs।

Browser GPU Technology

"GSWT Renderer" -- SIGGRAPH Asia 2025। GitHub। dynamic LOD और streaming के साथ अनंत 3D टेरेन के लिए Gaussian Splatting Wang Tiles इस्तेमाल करता WebGPU + Rust/Wasm renderer।

"GPU Compute in the Browser at the Speed of Native: WebGPU Marching Cubes" -- Usher (2024)। Blog। दिखाता है कि WebGPU compute parallel mesh generation एल्गोरिदम के लिए native-speed परफॉर्मेंस हासिल करता है।

Voxel Rendering और Large-Scale Scenes

"Aokana: A GPU-Driven Voxel Rendering Framework for Open World Games" -- 2025। arXiv:2505.02017। दसियों अरब voxels वाले scenes के लिए LOD और streaming के साथ Sparse Voxel DAG। पिछले state-of-the-art से 9x memory कमी और 4.8x तेज rendering। game engines के साथ integration के लिए डिज़ाइन किया गया।

Procedural Geometry और Resurfacing

"Real-time Procedural Resurfacing using GPU Mesh Shaders" -- Raad et al. (Eurographics 2025)। Paper। mesh shaders इस्तेमाल करते हुए render time पर मोटे control meshes से विस्तृत geometric सतहें जेनरेट करता है। memory में high-resolution ज्यामिति स्टोर किए बिना dynamic LOD सक्षम करता है।

Terrain Shadows

"Optimizing Terrain Shadows" -- AMD GPUOpen। Blog। बड़े पैमाने के टेरेन के लिए व्यावहारिक CSM optimization। cascade splitting, GPU-efficient shadow map rendering, और terrain-specific optimizations कवर करता है।

Virtual Geometry और Mesh Optimization

"Nanite WebGPU" -- Scthe (2024)। GitHub, Demo। UE5 Nanite आर्किटेक्चर का पूरा ब्राउज़र इम्प्लीमेंटेशन: meshlet LOD hierarchy, WGSL में software rasterizer, per-meshlet culling, billboard impostors।

"Billions of Triangles in Minutes" -- Kapoulkine (2025)। Blog। hierarchical clustered LOD generation के लिए Meshoptimizer v1.0। विशाल meshes को Nanite-style cluster DAGs में कुशलता से प्रोसेस करता है।

"Billboard Splatting (BBSplat)" -- 2024। arXiv:2411.08508। novel view synthesis के लिए learnable textured planar primitives जो 3D Gaussian Splatting बनाम 17x compression हासिल करते हैं।

Terrain Lighting और Global Illumination

"Global Illumination in Once Human" -- GDC 2025। Session। 16km ओपन वर्ल्ड के लिए hybrid GI: neural network compressed probes (69:1 ratio), ML-आधारित indoor/outdoor leak resolution, dynamic probe reactions।

"GI with AMD FidelityFX Brixelizer" -- GDC 2024। Paper। screen-space probes के साथ compute-आधारित sparse distance field cascades। कोई hardware ray-tracing जरूरी नहीं।

"Radiance Cascades" -- 2024। Blog। temporal accumulation के बिना cascaded radiance structures इस्तेमाल करती noiseless रियल-टाइम global illumination।

Level Design और Exploration

"PlotMap: Automated Layout Design for Building Game Worlds" -- 2023। arXiv:2309.15242। टेरेन पर narrative spatial constraints संतुष्ट करती AI-assisted POI placement।

"Spatial Exploration Triggers" -- Purdue University (FDG 2022)। Paper। चार डिज़ाइन पैटर्न जो प्लेयर अन्वेषण चलाते हैं: चरम पॉइंट, विज़ुअल बाधाएं, जगह से बाहर के objects, spatial connections।

Data Compression और Streaming

"Entropy-driven Progressive Compression of 3D Point Clouds" -- SGP 2024। Paper। adaptive quantization के साथ recursive space partitioning इस्तेमाल करती rate-distortion optimized progressive compression। variable-bandwidth नेटवर्क streaming के लिए उपयुक्त refinement streams बनाती है।

Interactive Editing

"WebGPU SDF Editor" -- Nijhoff (2026)। Project। real-time marching cubes, boolean ऑपरेशन, smooth blending, और octree space partitioning के साथ ब्राउज़र में full-featured SDF modeling। प्रति primitive 112 bytes।

River और Coastal Generation

"Procedural River Drainage Basins" -- Patel (Red Blob Games)। Project। Voronoi/triangle mesh edge classification इस्तेमाल करती drainage-first river generation। टेरेन एलिवेशन देने से पहले river hierarchies बनाती है।

"NEWTS1.0: Numerical Model of Coastal Erosion by Waves and Transgressive Scarps" -- MIT (2024)। Paper। uniform retreat और wave-driven इरोज़न इस्तेमाल करता सरलीकृत coastal इरोज़न मॉडल। असली भू-आकृति विज्ञान से मेल खाते headlands, खाड़ियां, sea stacks और मेहराब बनाता है।

आगे पढ़ें

• Browser 3D Open World Tech ब्राउज़र में एक मल्टीप्लेयर क्रिएटर दुनिया के लिए पूरा आर्किटेक्चर कवर करता है
• Web Games Tech Stack in 2026 WebGL, WebGPU और WebAssembly की बुनियादी बातें कवर करता है
• Three.js + USDC Tech Report ब्राउज़र में 3D assets लोड करने पर
• Frontier Open-Source Gen AI Models AI generation पाइपलाइन के लिए
• WebGPU getting started — GPU-ड्रिवन टेरेन के लिए compute shaders
• Web Workers for game logic — टेरेन generation को Workers पर offload करना
• Game physics libraries — टेरेन interaction और heightfield colliders के लिए physics
• Where to Find Free Game Assets — टेरेन rendering के लिए texture और material स्रोत

हम अपने क्रिएटर्स को एक साझा ओपन वर्ल्ड में रखना चाहते हैं। कोई लॉबी नहीं। कोई गैलरी नहीं। एक जीवंत 3D स्पेस जहाँ लोग घूम सकें, बना सकें और एक-दूसरे के काम से अचानक टकरा सकें। ऐसा कुछ जो ब्राउज़र टैब में लोड हो और एक ऐसी जगह जैसा लगे जहाँ रहना सार्थक हो।

यह एक मुश्किल समस्या है। Skyrim और The Witcher 3 ने अपनी दुनिया बनाने में सैकड़ों मिलियन डॉलर खर्च किए, और फिर भी वे डेडिकेटेड हार्डवेयर पर डिस्क पर दसियों गीगाबाइट के साथ शिप होते हैं। हम एक ब्राउज़र टैब, सैकड़ों खिलाड़ियों में साझा स्टेट, और एक ऐसी दुनिया का लक्ष्य रख रहे हैं जिसे क्रिएटर्स असल में फिर से आकार दे सकें।

यह गाइड दर्ज करती है कि टेक पर रिसर्च करते हुए हमें क्या मिला। आज क्या संभव है, क्या आने वाला है, और कौन-सा आर्किटेक्चर हमें वहाँ पहुँचाएगा।

Skyrim और The Witcher से हम क्या सीख सकते हैं

टेक्नोलॉजी चुनने से पहले, यह समझना मददगार है कि दो सबसे सफल ओपन वर्ल्ड असल में कैसे काम करते हैं। उनकी तकनीकें ब्राउज़र की पाबंदियों पर हैरान कर देने वाले ढंग से अच्छी तरह बैठती हैं।

Skyrim का सेल सिस्टम

Skyrim अपनी दुनिया को 57x37 बाहरी सेल्स के एक ग्रिड में बाँटता है, हर एक 4096x4096 गेम यूनिट (करीब 59 मीटर) का। इंजन किसी भी समय खिलाड़ी के चारों ओर सेल्स का 5x5 ग्रिड लोड करता है। जैसे-जैसे आप चलते हैं, पीछे के किनारे की सेल्स अनलोड होती हैं जबकि आगे के किनारे की सेल्स स्ट्रीम होकर आती हैं। आंतरिक स्पेस (डंजन, इमारतें) अलग वर्ल्डस्पेस होते हैं जो दरवाज़े के ट्रिगर के ज़रिए लोड होते हैं।

यह सीधे एक ब्राउज़र वर्ल्ड पर लागू होता है। आप पूरा मैप लोड नहीं करते। आप खिलाड़ी के चारों ओर का एक मोहल्ला लोड करते हैं और जैसे-जैसे वे चलते हैं चंक्स बदलते रहते हैं। मुख्य बात: Skyrim कभी आपको दूर के टेरेन की पूरी डिटेल नहीं देखने देता। यह एक मल्टी-रिज़ॉल्यूशन तरीका अपनाता है।

Skyrim में LOD (Level of Detail) टियर:

• 1-2 सेल्स के भीतर पूरी डिटेल (खिलाड़ी का तुरंत आसपास का इलाका)
• मध्यम दूरी पर सरल मेश (ऑब्जेक्ट छोटी ज्यामिति खो देते हैं)
• मध्यम दूरी से आगे पेड़ों और चट्टानों के लिए बिलबोर्ड इम्पोस्टर
• टेरेन LOD दूर के परिदृश्य के लिए पहले से बेक की गई कम-रिज़ॉल्यूशन मेश का उपयोग करता है
• ऑब्जेक्ट फेड दूरियाँ हर ऑब्जेक्ट के हिसाब से ट्यून की गई हैं (घास पहले फेड होती है, इमारतें आखिर में)

Skyrim का परिदृश्य प्रति सेल 32x32 वर्टेक्स पैच के साथ एक हाइटमैप-आधारित टेरेन का उपयोग करता है। हर पैच पर अलग टेक्सचर हो सकते हैं जो अल्फा मैप के साथ ब्लेंड होते हैं। इसे स्टोर और रेंडर करना सस्ता है। एक सेल का टेरेन डेटा किलोबाइट में नापा जाता है, मेगाबाइट में नहीं।

हम क्या लागू कर सकते हैं: चंक-आधारित स्ट्रीमिंग, हाइटमैप टेरेन, आक्रामक LOD, आंतरिक/बाहरी अलगाव, और यह विचार कि दूर का टेरेन ज्यामितीय रूप से सटीक होने की ज़रूरत नहीं रखता, बस देखने में विश्वसनीय होना चाहिए।

The Witcher 3 का स्ट्रीमिंग आर्किटेक्चर

The Witcher 3 की दुनिया Skyrim से बड़ी है (सभी क्षेत्रों में करीब 136 km2) और एक ज़्यादा परिष्कृत स्ट्रीमिंग सिस्टम का उपयोग करती है। CD Projekt RED ने एक कस्टम इंजन (REDengine 3) बनाया जहाँ दुनिया को स्ट्रीमिंग सेक्टर में बाँटा गया है, किसी सख्त ग्रिड में नहीं।

हर सेक्टर में कंटेंट लेयर्स का एक पदानुक्रम होता है:

• टेरेन 4 LOD लेवल के साथ पैच के रूप में स्ट्रीम होता है
• फोलिएज दूरी-आधारित कलिंग के साथ GPU इंस्टैंसिंग का उपयोग करता है
• स्टैटिक ज्यामिति (इमारतें, चट्टानें) टेरेन से अलग स्ट्रीम होती है
• गेमप्ले ऑब्जेक्ट (NPC, आइटम, ट्रिगर) क्वेस्ट स्टेट और निकटता के आधार पर लोड होते हैं

रेंडरर भौतिकी-आधारित मटेरियल के साथ डिफर्ड शेडिंग का उपयोग करता है। एक ट्रिक जो खास तौर पर प्रासंगिक है: The Witcher 3 आक्रामक रूप से इम्पोस्टर का उपयोग करता है। 200 मीटर दूर का पेड़ शाखाओं और पत्तियों वाला 3D मॉडल नहीं है। यह एक सपाट टेक्सचर्ड क्वाड है जो हमेशा कैमरे की ओर मुँह करता है। इंजन इन इम्पोस्टर को कई कोणों से पहले से रेंडर करता है और कैमरा हिलने पर उन्हें बदलता है। आपको कभी पता नहीं चलता क्योंकि वे काफ़ी दूर होते हैं।

वर्ल्ड कंपोज़िशन: The Witcher 3 का ओपन वर्ल्ड अलग-अलग टीमों ने एक साथ काम करते हुए परतों में बनाया था। टेरेन टीम ने परिदृश्य गढ़ा। एनवायरनमेंट आर्ट टीम ने संरचनाएँ रखीं। क्वेस्ट टीम ने ट्रिगर और NPC पाथ जोड़े। इस परतदार कंपोज़िशन सिस्टम ने एक बड़ी टीम को एक-दूसरे के काम में दखल दिए बिना काम करने दिया।

हम क्या लागू कर सकते हैं: परतदार वर्ल्ड कंपोज़िशन (क्रिएटर प्लेटफ़ॉर्म के लिए बेहद ज़रूरी), दूर के ऑब्जेक्ट के लिए इम्पोस्टर रेंडरिंग, कई लाइट स्रोतों के लिए डिफर्ड रेंडरिंग, और यह समझ कि स्ट्रीमिंग कंटेंट-अवेयर होनी चाहिए (जो आंतरिक भाग आप देख नहीं सकते उन्हें लोड न करें, जिन NPC के पास आप नहीं हैं उन्हें स्पॉन न करें)।

Breath of the Wild का केमिस्ट्री इंजन

ओपन वर्ल्ड डिज़ाइन के लिए Nintendo का तरीका सामान्य फ़ॉर्मूले को उलट देता है। दुनिया को स्क्रिप्टेड कंटेंट से भरने के बजाय, उन्होंने सिस्टमिक नियम बनाए और खिलाड़ियों को उभरते व्यवहार की खोज करने दी। आग घास में फैलती है। आँधी-तूफ़ान में धातु बिजली का संचालन करती है। हवा ऑब्जेक्ट को बहा ले जाती है। एक सुसंगत भौतिकी/रसायन परत के ज़रिए हर चीज़ हर चीज़ के साथ इंटरैक्ट करती है।

यह एक क्रिएटर वर्ल्ड के लिए मायने रखता है क्योंकि यह सुझाता है कि दुनिया खुद किसी भी अलग रखे गए ऑब्जेक्ट से ज़्यादा दिलचस्प हो सकती है। अगर क्रिएटर्स मटेरियल गुण और इंटरैक्शन नियम परिभाषित कर सकें (सिर्फ़ स्टैटिक मेश रखने के बजाय), तो दुनिया को उभरता व्यवहार मिलता है जो उन इलाकों में भी एक्सप्लोरेशन को सार्थक बनाता है जिन्हें किसी ने जानबूझकर डिज़ाइन नहीं किया।

BotW से तकनीकी सीख:

• अपेक्षाकृत कम पॉलीगॉन संख्या और रिज़ॉल्यूशन (Switch पर डॉक्ड 900p)। स्टाइलाइज़्ड सेल-शेडेड लुक कम फ़िडेलिटी को छिपा देता है। एक ब्राउज़र वर्ल्ड आज समान विज़ुअल क्वालिटी हासिल कर सकता है।
• डिस्टेंस रेंडरिंग एक टून-शेडेड फॉग का उपयोग करता है जो वॉटरकलर-स्टाइल स्काईबॉक्स में फेड हो जाता है। रेंडर करने में सस्ता, व्यवहार में सुंदर। इस तरह का वायुमंडलीय परिप्रेक्ष्य एक फ्रैगमेंट शेडर में लगभग मुफ़्त है।
• दुनिया करीब 84 km2 की है लेकिन विरल है। मैप का ज़्यादातर हिस्सा घूमने योग्य टेरेन है जिस पर रुचि के बिंदु बिखरे हुए हैं। घना कंटेंट कस्बों और श्राइन के लिए आरक्षित है। यह "विरल लेकिन दिलचस्प" तरीका The Witcher 3 के घनी आबादी वाले Novigrad की तुलना में एसेट की ज़रूरतों को नाटकीय रूप से कम कर देता है।
• भौतिकी ऑब्जेक्ट में मटेरियल टैग (लकड़ी, धातु, खाना, विस्फोटक) होते हैं जो इंटरैक्शन तय करते हैं। असली नियमों की संख्या कम है (शायद 20-30 इंटरैक्शन प्रकार) लेकिन वे ऐसे तरीकों से मिलते हैं जो अनंत महसूस होते हैं।

GTA V की वर्ल्ड लेयरिंग

Los Santos के लिए Rockstar का तरीका एक अलग सबक सिखाता है। GTA V की दुनिया जीवंत महसूस होती है परतदार एम्बिएंट सिस्टम के कारण, इसलिए नहीं कि हर NPC के पास एक क्वेस्ट है।

शहर में ट्रैफ़िक सिस्टम हैं जो एक सड़क नेटवर्क पर सैकड़ों वाहनों का सिमुलेशन करते हैं। पैदल यात्री रूट पर चलते हैं, खिलाड़ी पर प्रतिक्रिया देते हैं, और आपस में इंटरैक्ट करते हैं। दिन का समय आबादी के घनत्व, मौजूद NPC के प्रकार और एम्बिएंट गतिविधि को बदल देता है। मौसम ड्राइविंग भौतिकी और NPC व्यवहार को प्रभावित करता है।

एक क्रिएटर वर्ल्ड के लिए, सीख यह है कि एम्बिएंट लाइफ़ ही उस दुनिया में फ़र्क़ पैदा करती है जो म्यूज़ियम जैसी महसूस होती है और जो एक जगह जैसी महसूस होती है। साधारण व्यवहार भी (सिर के ऊपर उड़ते पक्षी, किनारे से टकराती लहरें, इमारतों के बीच चलते NPC) एक जीवंत दुनिया का भ्रम पैदा करते हैं।

GTA V से तकनीकी सीख:

• मैप 75 km2 का है और आक्रामक LOD के साथ एक स्ट्रीमिंग सिस्टम का उपयोग करता है जो वेग के आधार पर लोड करता है (तेज़ ड्राइविंग चलने से आगे तक लोड करती है)।
• GTA Online इस दुनिया में एक साथ 30 खिलाड़ियों को रखता है। 30 पर भी, Rockstar ने पाया कि उन्हें स्थानिक इंटरेस्ट मैनेजमेंट की ज़रूरत है: आपको पास के खिलाड़ियों के बारे में विस्तृत अपडेट मिलते हैं और दूर वालों के बारे में कम बार। हमारे 200-खिलाड़ी लक्ष्य पर भी वही सिद्धांत लागू होता है।
• GTA V की एसेट पाइपलाइन अब तक की सबसे कुशल में से एक है। पूरा गेम करीब 80 GB में आ जाता है, अत्यधिक टेक्सचर कम्प्रेशन, मेश शेयरिंग, और प्रोसीजरल डिटेल के कारण। इसके बिल्डिंग इंटीरियर मॉड्यूलर टुकड़ों का खूब दोबारा उपयोग करते हैं।
• गेम एक परिष्कृत इम्पोस्टर सिस्टम का उपयोग करता है जहाँ दूर की इमारतें असल में एक साथ कंपोज़िट की गई सपाट फ़ोटो हैं। खिलाड़ी को कभी पता नहीं चलता क्योंकि ट्रांज़िशन दूरियाँ विशिष्ट देखने के कोणों के हिसाब से ट्यून की गई हैं।

Elden Ring का सीमलेस ओपन वर्ल्ड

FromSoftware ने Elden Ring को Dark Souls के उसी इंजन पर बनाया लेकिन उसे एक ओपन वर्ल्ड तक बढ़ाया। नतीजा दिलचस्प है क्योंकि यह दिखाता है कि एक अपेक्षाकृत छोटी टीम (Rockstar या CD Projekt की तुलना में) कैसे एक बड़ा ओपन वर्ल्ड बना सकती है।

ट्रिक है घनत्व में भिन्नता। Elden Ring का मैप विशाल है (करीब 79 km2) लेकिन बड़े हिस्से खुले टेरेन हैं जिनमें बिखरे हुए दुश्मन और रुचि के बिंदु हैं। घना, हाथ से बनाया गया कंटेंट (Stormveil Castle जैसे Legacy Dungeons) ओपन वर्ल्ड में जड़ा हुआ है और वही आंतरिक/बाहरी अलगाव उपयोग करता है जो Skyrim करता है।

Elden Ring से तकनीकी सीख:

• दुनिया बड़ी टाइल्स में स्ट्रीम होती है। घोड़े पर आप बहुत दूर तक देख सकते हैं, लेकिन दूर का टेरेन बेहद सरल है। पास में, डिटेल Dark Souls 3 के बराबर है।
• लोडिंग स्क्रीन केवल फ़ास्ट-ट्रैवल करते या कुछ खास डंजन में घुसते वक़्त दिखती हैं। ओपन वर्ल्ड खुद बिना रुकावट के स्ट्रीम होता है।
• गेम एनवायरनमेंट एसेट का खूब दोबारा उपयोग करता है। वही पेड़ के मॉडल, चट्टान की संरचनाएँ, और खंडहर के टुकड़े मैप भर में अलग-अलग व्यवस्थाओं में दिखते हैं। व्यवस्था और लाइटिंग में पर्याप्त विविधता के साथ, दोहराव नज़र नहीं आता। यह सीधे एक क्रिएटर वर्ल्ड पर लागू होता है जहाँ मॉड्यूलर टुकड़ों की एक लाइब्रेरी अनंत विविधता पैदा कर सकती है।
• मल्टीप्लेयर सेशन-आधारित है (दूसरे खिलाड़ियों को अपनी दुनिया में बुलाना), स्थायी नहीं। लेकिन असिंक्रोनस फ़ीचर (संदेश, ब्लडस्टेन, दूसरे खिलाड़ियों के घोस्ट) एक स्थायी सर्वर के नेटवर्किंग ओवरहेड के बिना साझा अस्तित्व का अहसास पैदा करते हैं। ये एम्बिएंट मल्टीप्लेयर फ़ीचर एक ब्राउज़र वर्ल्ड में जोड़ना सस्ता होगा।

No Man's Sky: प्रोसीजरल हर चीज़

No Man's Sky प्रोसीजरल जनरेशन का चरम उदाहरण है। एक साझा सीड से जनरेट किए गए 18 क्विंटिलियन ग्रह, ताकि हर खिलाड़ी वही ब्रह्मांड देखे बिना उसमें से कुछ भी सर्वर पर स्टोर किए।

जनरेशन पाइपलाइन चरणों में काम करती है: गैलेक्सी-स्तर के सीड तारों की स्थिति तय करते हैं, तारा सीड ग्रहों की संख्या और प्रकार तय करते हैं, ग्रह सीड टेरेन जनरेशन (मल्टी-ऑक्टेव नॉइज़), बायोम असाइनमेंट, फ़्लोरा/फ़ौना प्रजातियाँ, कलर पैलेट, और संसाधन वितरण चलाते हैं। हर चीज़ सीड से नियतात्मक रूप से कंप्यूट होती है, इसलिए वही निर्देशांक देखने वाले दो खिलाड़ी कोई ग्रह डेटा आपस में बदले बिना वही ग्रह देखते हैं।

No Man's Sky से तकनीकी सीख:

• टेरेन जनरेशन नॉइज़ फ़ंक्शन की एक श्रृंखला के साथ वॉक्सेल-आधारित मार्चिंग क्यूब्स का उपयोग करता है। इससे गुफाएँ, ओवरहैंग, और तैरते द्वीप संभव होते हैं जिन्हें हाइटमैप टेरेन दिखा नहीं सकता। बदले में प्रति चंक ज़्यादा कंप्यूट लागत आती है, लेकिन नतीजा देखने में ज़्यादा दिलचस्प टेरेन होता है।
• बेस-बिल्डिंग सिस्टम सबसे क़रीब है उस चीज़ के जिसकी हम कल्पना कर रहे हैं। खिलाड़ी ऐसी संरचनाएँ रखते हैं जो सर्वर पर बनी रहती हैं और दूसरे खिलाड़ियों को दिखती हैं। बेस डेटा कॉम्पैक्ट है (स्थिति और घुमाव वाले पार्ट की एक सूची) और तब स्ट्रीम होता है जब कोई ग्रह पर जाता है।
• गेम की शुरुआत में अनंत विविधता के बावजूद दोहराव वाले कंटेंट के लिए आलोचना हुई थी। सीड-आधारित जनरेशन अनंत टेरेन पैदा कर सकती है लेकिन सीमित आश्चर्य। सीख: प्रोसीजरल जनरेशन कैनवस के लिए काम करती है, लेकिन क्रिएटर द्वारा रखा गया कंटेंट ही किसी जगह को डिज़ाइन किया हुआ और इरादतन महसूस कराता है।
• Hello Games ने लॉन्च के सालों बाद मल्टीप्लेयर जोड़ा। 32 तक खिलाड़ी पूरी बिल्डिंग और एक्सप्लोरेशन के साथ एक सेशन साझा करते हैं। नेटवर्क मॉडल सरल है: एक खिलाड़ी होस्ट करता है, बाक़ी कनेक्ट होते हैं। स्थायी स्टेट वाले एक ब्राउज़र वर्ल्ड के लिए, एक सर्वर-अथॉरिटेटिव मॉडल बेहतर काम करता है, लेकिन No Man's Sky साबित करता है कि साझा प्रोसीजरल वर्ल्ड संभव हैं।

Minecraft: क्रिएटर वर्ल्ड्स के लिए ब्लूप्रिंट

जो हम बना रहे हैं उसके लिए Minecraft सबसे अहम संदर्भ बिंदु है, किसी भी ग्राफ़िकल AAA टाइटल से ज़्यादा। 30 करोड़ कॉपी बिकीं। दुनिया अनंत रूप से जनरेट होती है, पूरी तरह विनाशकारी है, और मल्टीप्लेयर है। Minecraft में क्रिएटर्स सिर्फ़ ऑब्जेक्ट नहीं रखते। वे खुद टेरेन को फिर से आकार देते हैं।

Minecraft से तकनीकी सीख:

• दुनिया 16x16x384 ब्लॉक चंक्स में बँटी है। केवल खिलाड़ी के पास के चंक्स लोड होते हैं (रेंडर डिस्टेंस कॉन्फ़िगर करने योग्य है)। यह Skyrim जैसा ही चंक स्ट्रीमिंग पैटर्न है लेकिन पूरी तरह एडिट करने योग्य टेरेन के साथ।
• हर चंक एक पैलेट-कम्प्रेस्ड ब्लॉक ID की ऐरे के रूप में स्टोर होता है। केवल 5 अलग ब्लॉक प्रकार वाला एक चंक प्रति ब्लॉक पूरे ब्लॉक ID के बजाय एक 4-बिट पैलेट इंडेक्स स्टोर करता है। इससे चंक डेटा बहुत कॉम्पैक्ट हो जाता है (कम्प्रेशन के बाद आम तौर पर प्रति चंक 10-50 KB)।
• Minecraft का मल्टीप्लेयर प्रोटोकॉल अच्छी तरह दर्ज है और अपेक्षाकृत सरल है। जैसे-जैसे खिलाड़ी चलता है सर्वर चंक डेटा भेजता है। ब्लॉक बदलाव छोटे डेल्टा अपडेट के रूप में प्रसारित होते हैं (स्थिति + नया ब्लॉक प्रकार)। यह बिल्कुल वही मॉडल है जो हम क्रिएटर एडिट के लिए उपयोग करेंगे।
• गेम Java में चलता है और अब इसका C++ में एक Bedrock Edition है। ब्राउज़र-आधारित Minecraft क्लोन (ClassiCube, eaglercraft) हैं जो साबित करते हैं कि मूल अवधारणा WebGL में काम करती है। वे आम तौर पर 60fps पर 8-12 चंक रेंडर डिस्टेंस संभालते हैं, जो करीब 200-400 मीटर का दृश्य देता है।
• Minecraft का मॉडिंग इकोसिस्टम इसकी असली खाई है। मॉड नए ब्लॉक, एंटिटी, बायोम, और गेमप्ले सिस्टम जोड़ते हैं। एक क्रिएटर वर्ल्ड के लिए, यह सुझाता है कि विस्तार-योग्यता उतनी ही मायने रखती है जितना मूल अनुभव। अगर क्रिएटर्स नए इंटरैक्शन प्रकार परिभाषित कर सकें (सिर्फ़ ऑब्जेक्ट रखने के बजाय), तो दुनिया समय के साथ समृद्ध होती है।
• Redstone (Minecraft का इन-गेम वायरिंग सिस्टम) दिखाता है कि अगर आप क्रिएटर्स को सरल, संयोजन-योग्य प्रिमिटिव दें तो वे जटिल सिस्टम बनाएँगे। लॉजिक गेट, ऑटोमैटिक फ़ार्म, कैलकुलेटर। सरल नियम-सेट असाधारण जटिलता पैदा करता है। यह BotW के केमिस्ट्री इंजन जैसा ही सबक है।

AAA ओपन वर्ल्ड्स में सामान्य पैटर्न

इन सभी टाइटलों को देखते हुए, वही पैटर्न बार-बार दिखते हैं:

स्थानिक विभाजन सार्वभौमिक है। चाहे वह सेल्स हों (Bethesda), सेक्टर (CD Projekt), चंक्स (Mojang/Rockstar), या टाइल्स (FromSoftware), हर ओपन वर्ल्ड स्पेस को लोड करने योग्य इकाइयों में बाँटता है। कोई इंजन पूरी दुनिया को मेमोरी में रखने की कोशिश नहीं करता।

मल्टी-रिज़ॉल्यूशन हर चीज़। टेरेन, मेश, टेक्सचर, और यहाँ तक कि ऑडियो सभी के कई क्वालिटी लेवल होते हैं। आपको जो रिज़ॉल्यूशन मिलता है वह इस पर निर्भर करता है कि आप कितने क़रीब हैं और ऑब्जेक्ट कितना अहम है।

ऑक्लूज़न कलिंग कच्चे ट्रायएंगल थ्रूपुट से ज़्यादा मायने रखती है। जो आप देख नहीं सकते उसे रेंडर न करना, जो आप देख सकते हैं उसे ऑप्टिमाइज़ करने से ज़्यादा परफ़ॉर्मेंस बचाता है। Skyrim एक सरल दूरी-आधारित सिस्टम उपयोग करता है। The Witcher 3 बड़े ऑक्लूडर (इमारतें, चट्टानें) के साथ सॉफ़्टवेयर ऑक्लूज़न उपयोग करता है। UE5 के Nanite जैसे आधुनिक इंजन इसे हार्डवेयर ऑक्लूज़न क्वेरी के साथ और आगे ले जाते हैं।

असिंक्रोनस लोडिंग ट्रांज़िशन छिपा देती है। ये गेम ओपन वर्ल्ड के लिए लोडिंग स्क्रीन नहीं दिखाते (केवल फ़ास्ट-ट्रैवल या आंतरिक ट्रांज़िशन के लिए)। वे बैकग्राउंड थ्रेड पर कंटेंट लोड करते हैं, समानांतर में डीकम्प्रेस करते हैं, और धीरे-धीरे नया कंटेंट स्वैप करते हैं।

पॉलीगॉन संख्या के ऊपर आर्ट डायरेक्शन। Skyrim 2011 में ऐसे ग्राफ़िक्स के साथ शिप हुआ जो तब भी मामूली थे। BotW टैबलेट-श्रेणी की चिप पर चलता है और सुंदर दिखता है। Minecraft 16x16 पिक्सेल टेक्सचर उपयोग करता है और अब तक के सबसे विज़ुअली पहचाने जाने वाले गेमों में से एक है। एक ब्राउज़र वर्ल्ड के लिए, यह बहुत मायने रखता है। कम फ़िडेलिटी पर अच्छी तरह डायरेक्ट की गई आर्ट स्टाइल हमेशा एक तकनीकी रूप से उन्नत लेकिन कलात्मक रूप से सपाट दुनिया को मात देगी।

सिस्टमिक डिज़ाइन स्क्रिप्टेड कंटेंट को मात देता है। BotW का केमिस्ट्री इंजन, Minecraft के ब्लॉक इंटरैक्शन, और GTA V के ट्रैफ़िक सिस्टम सभी सरल नियमों से उभरता व्यवहार पैदा करते हैं। यह बनाने में सस्ता है, चलाने में सस्ता है, और हाथ से बनाए गए स्क्रिप्टेड अनुक्रमों से ज़्यादा खिलाड़ी कहानियाँ पैदा करता है। एक क्रिएटर वर्ल्ड के लिए, सिस्टमिक डिज़ाइन का मतलब है कि दुनिया उन इलाकों में भी दिलचस्प बनी रहती है जिन्हें किसी ने जानबूझकर डिज़ाइन नहीं किया।

क्रिएटर द्वारा रखे गए कंटेंट को स्थायित्व और दृश्यता चाहिए। Minecraft बेस, No Man's Sky बेस, और GTA Online प्रॉपर्टी सभी सेशन भर बनी रहती हैं और दूसरे खिलाड़ियों को दिखती हैं। क्रिएटर कंटेंट के लिए डेटा मॉडल हमेशा कॉम्पैक्ट होता है (पार्ट ID + ट्रांसफ़ॉर्म) जबकि विज़ुअल प्रतिनिधित्व समृद्ध होता है (क्लाइंट डेटा को पूरे 3D सीन में फैलाता है)।

रेंडरिंग: एक ब्राउज़र असल में क्या कर सकता है?

Three.js

Three.js नींव है। इसकी सबसे बड़ी कम्युनिटी है (100K से ज़्यादा GitHub स्टार), सबसे ज़्यादा उदाहरण, और सबसे व्यापक संगतता। यह WebGL 2 को अमूर्त करता है और WebGPURenderer के ज़रिए प्रयोगात्मक WebGPU सपोर्ट रखता है।

एक ओपन वर्ल्ड के लिए, Three.js आपको देता है:

• फोलिएज, चट्टानों, और दोहराई जाने वाली ज्यामिति के लिए इंस्टैंस्ड रेंडरिंग (InstancedMesh)
• अंतर्निहित LOD सिस्टम (THREE.LOD दूरी के हिसाब से मेश स्वैप करता है)
• प्रति ऑब्जेक्ट स्वचालित फ़्रस्टम कलिंग
• कस्टम BufferGeometry या हाइटमैप-आधारित PlaneGeometry के ज़रिए टेरेन
• MeshStandardMaterial और MeshPhysicalMaterial के ज़रिए PBR मटेरियल
• EffectComposer के ज़रिए पोस्ट-प्रोसेसिंग (bloom, SSAO, tone mapping)
• कस्टम कोड के ज़रिए कैस्केडेड शैडो मैपिंग संभव के साथ शैडो मैप
• प्राथमिक एसेट फ़ॉर्मेट के रूप में glTF/GLB (कॉम्पैक्ट, GPU-तैयार)

Three.js के पास टूल्स का एक सक्रिय इकोसिस्टम भी है जो ओपन वर्ल्ड के लिए मायने रखता है। three-mesh-bvh जटिल मेश पर रेकास्टिंग और स्थानिक क्वेरी को तेज़ करता है। postprocessing (vanruesc द्वारा) Three के अंतर्निहित स्टैक से ज़्यादा परफ़ॉर्मेंट पोस्ट-प्रोसेसिंग स्टैक देता है। three-gpu-pathtracing संदर्भ-गुणवत्ता वाली रेंडरिंग सक्षम करता है।

ओपन वर्ल्ड्स के लिए सीमाएँ: Three.js के पास कोई अंतर्निहित सीन ग्राफ़ नहीं है जो बड़े पैमाने पर स्ट्रीमिंग, LOD मैनेजमेंट, या स्थानिक विभाजन संभाले। आप वे ख़ुद बनाते हैं। कोई अंतर्निहित एंटिटी कंपोनेंट सिस्टम (ECS), कोई भौतिकी, और कोई टेरेन सिस्टम नहीं है। यह एक रेंडरर है, इंजन नहीं। यह असल में एक कस्टम ओपन वर्ल्ड के लिए फ़ायदा है क्योंकि आप मेमोरी लेआउट और लोडिंग रणनीति को नियंत्रित करते हैं, लेकिन इसका मतलब है शुरुआत में ज़्यादा काम।

const lod = new THREE.LOD();
lod.addLevel(highDetailMesh, 0);
lod.addLevel(mediumDetailMesh, 50);
lod.addLevel(lowDetailMesh, 200);
lod.addLevel(impostorSprite, 500);
scene.add(lod);

Babylon.js

Babylon.js दूसरा बड़ा दावेदार है। Microsoft-समर्थित, इसमें ओपन वर्ल्ड्स की विशिष्ट समस्या के लिए Three.js से ज़्यादा गहरे अंतर्निहित फ़ीचर हैं।

प्रासंगिक अंतर्निहित फ़ीचर:

• बड़े सीन की कुशल कलिंग के लिए ऑक्ट्री-आधारित सीन विभाजन
• बड़े पैमाने पर इंस्टैंस्ड रेंडरिंग के लिए Solid Particle System
• अंतर्निहित LOD और मल्टी-टेक्सचर स्प्लैटिंग के साथ हाइटमैप से टेरेन
• विज़ुअल शेडर निर्माण के लिए Node Material Editor
• WebGPU सपोर्ट (Three.js से ज़्यादा परिपक्व, क्योंकि Babylon ने पहले निवेश किया)
• Havok physics इंटीग्रेशन (Wasm-कम्पाइल्ड, प्रोडक्शन-क्वालिटी)
• प्रोग्रेसिव लोडिंग के साथ glTF स्ट्रीमिंग

Babylon का DynamicTerrain एक्सटेंशन हाइटमैप डेटा से चलते-चलते टेरेन चंक्स जनरेट करता है, LOD अपने आप संभालता है, और टेक्सचर स्प्लैटिंग सपोर्ट करता है। यह उस चीज़ के बहुत क़रीब है जो Skyrim करता है, बनिस्बत उसके जो Three.js बॉक्स से बाहर देता है।

const terrain = new BABYLON.DynamicTerrain("terrain", {
  terrainSub: 100,
  mapData: heightmapData,
  mapSubX: 1000,
  mapSubZ: 1000,
}, scene);
terrain.LODLimits = [4, 3, 2, 1];

बदलाव की क़ीमत: Babylon.js एक बड़ी लाइब्रेरी है (पूरा बिल्ड ~1-2MB मिनिफ़ाइड बनाम Three.js ~600KB पर)। लेकिन एक ओपन वर्ल्ड के लिए, आप शायद Three.js में इतना कस्टम कोड जोड़ेंगे कि आकार का फ़र्क़ नगण्य हो जाए। Babylon के पास अपना Node Material सिस्टम, इंस्पेक्टर, और डेव टूल्स भी हैं, जो इटरेशन को तेज़ करते हैं।

Babylon.js 8.0 (मार्च 2025 में रिलीज़) ने इसे यहाँ इंजन कोर के रूप में और मज़बूत किया। सभी कोर इंजन शेडर अब GLSL और WGSL दोनों में शिप होते हैं, इसलिए WebGPU बिना किसी कन्वर्ज़न लेयर के काम करता है और WebGPU बंडल पहले से करीब आधे आकार का है। उसी रिलीज़ ने Havok का पूरा कैरेक्टर कंट्रोलर इंजन में लाया, एरिया लाइट्स, एक दोबारा बनाया गया ऑडियो इंजन, और Gaussian splatting सुधार (SPZ और कम्प्रेस्ड PLY फ़ॉर्मेट, स्फेरिकल हार्मोनिक्स, और कम मेमोरी/CPU फ़ुटप्रिंट)।

PlayCanvas

PlayCanvas का ज़िक्र करना ज़रूरी है क्योंकि यह सबसे प्रोडक्शन-प्रमाणित वेब-फ़र्स्ट 3D इंजन है। Snap, Facebook, और कई विज्ञापन क्लाइंट ने इसके साथ जटिल 3D अनुभव शिप किए हैं। इंजन करीब 1MB का है, तेज़ी से लोड होता है, और क्लाउड एडिटर सहयोगी वर्ल्ड बिल्डिंग सक्षम करता है।

खासकर एक ओपन वर्ल्ड के लिए, PlayCanvas ड्रॉ कॉल ऑप्टिमाइज़ेशन के लिए बैच ग्रुप, एक अंतर्निहित लाइटमैपर, और Gaussian splatting सपोर्ट देता है (फ़ोटोग्रामेट्री-कैप्चर किए गए असली दुनिया के एनवायरनमेंट के लिए प्रासंगिक)। रनटाइम टाइट है और मोबाइल ब्राउज़र के लिए अच्छी तरह ऑप्टिमाइज़ किया हुआ है।

WebGPU: परफ़ॉर्मेंस की चाबी

WebGPU ब्राउज़र ओपन वर्ल्ड्स के लिए समीकरण बदल देता है। दो फ़ीचर जो सबसे ज़्यादा मायने रखते हैं:

कंप्यूट शेडर GPU-साइड टेरेन जनरेशन, फोलिएज प्लेसमेंट, पार्टिकल सिमुलेशन, और यहाँ तक कि सरल भौतिकी सक्षम करते हैं। एक WebGL वर्ल्ड में, यह सब JavaScript में CPU पर चलता है। WebGPU के साथ, आप टेरेन पैच पूरी तरह GPU पर जनरेट कर सकते हैं, LOD ट्रांज़िशन GPU पर कंप्यूट कर सकते हैं, और कलिंग पास GPU पर चला सकते हैं। यह CPU को नेटवर्किंग, गेम लॉजिक, और कंटेंट स्ट्रीमिंग के लिए मुक्त कर देता है।

इनडायरेक्ट रेंडरिंग GPU को कंप्यूट शेडर आउटपुट के आधार पर तय करने देती है कि क्या ड्रॉ करना है। आप एक ड्रॉ कॉल सबमिट करते हैं, और GPU दूरी के आधार पर तय करता है कि हर LOD लेवल के लिए कितने इंस्टैंस रेंडर करने हैं। आधुनिक इंजन इसी तरह घास के लाखों तिनके या पेड़ संभालते हैं। इनडायरेक्ट रेंडरिंग के बिना (जो WebGL सपोर्ट नहीं करता), CPU को सब कुछ सॉर्ट और बैच करना पड़ता है, जो घने सीन में बॉटलनेक बन जाता है।

WebGPU अब हर बड़े ब्राउज़र में शिप होता है। Chrome और Edge के पास यह वर्शन 113 से है, Firefox ने इसे Windows (141) और Apple Silicon macOS (145) पर जोड़ा, और Safari 26 ने इसे 2025 के आख़िर में macOS, iOS, iPadOS, और visionOS पर लाया। इससे वैश्विक सपोर्ट करीब 82% हो जाता है, मोबाइल समेत (Chrome for Android और Samsung Internet भी इसे शिप करते हैं)। आप फिर भी पुराने ब्राउज़र और उन डिवाइस के लिए एक WebGL 2 फ़ॉलबैक रखेंगे जहाँ WebGPU सक्षम नहीं है, लेकिन यह खाई तेज़ी से बंद हुई है।

@compute @workgroup_size(64)
fn generateTerrain(@builtin(global_invocation_id) id: vec3<u32>) {
    let worldPos = vec2<f32>(f32(id.x), f32(id.y)) * cellSize + worldOffset;
    let height = fbmNoise(worldPos, octaves, persistence);
    heightmap[id.x + id.y * width] = height;
}

अनुशंसित रेंडरिंग स्टैक

डेस्कटॉप पर क्रिएटर्स को लक्ष्य करने वाले एक ब्राउज़र ओपन वर्ल्ड के लिए:

प्राथमिक: Three.js या Babylon.js, जहाँ उपलब्ध हो वहाँ WebGPU रेंडरर के साथ, WebGL 2 फ़ॉलबैक। Babylon के पास मज़बूत अंतर्निहित ओपन-वर्ल्ड प्रिमिटिव हैं। Three.js के पास बड़ी कम्युनिटी और ज़्यादा लचीलापन है।

हमारी पसंद: इंजन कोर के लिए Babylon.js, अंतर्निहित टेरेन LOD, ऑक्ट्री कलिंग, Havok physics (Wasm), और परिपक्व WebGPU सपोर्ट के कारण। जहाँ Babylon में कमी हो वहाँ Three.js इकोसिस्टम टूल्स उपयोग करें (जैसे, स्थानिक क्वेरी के लिए mesh BVH)। सब कुछ एक कस्टम वर्ल्ड-स्ट्रीमिंग लेयर में लपेटें।

वर्ल्ड स्ट्रीमिंग आर्किटेक्चर

यह मुश्किल हिस्सा है। एक ब्राउज़र टैब को डेस्कटॉप पर करीब 2-4 GB मेमोरी मिलती है (ब्राउज़र द्वारा थोपी गई सीमाएँ), मोबाइल पर करीब 1 GB, और कोई सीधा डिस्क एक्सेस नहीं। हर चीज़ नेटवर्क के ज़रिए आती है। आपको एक ऐसा आर्किटेक्चर चाहिए जो दिखने वाली दुनिया को मेमोरी में रखे जबकि खिलाड़ी जिस दिशा में बढ़ रहा है उससे ठीक आगे का कंटेंट स्ट्रीम करे।

चंक-आधारित वर्ल्ड ग्रिड

Skyrim के सेल सिस्टम की तरह, दुनिया को चंक्स के एक नियमित ग्रिड में बाँटें। हर चंक एक स्वतंत्र इकाई है जिसे अलग से लोड, रेंडर, और अनलोड किया जा सकता है।

चंक का आकार मायने रखता है। बहुत छोटा हो तो आप लगातार ऊँचे ओवरहेड के साथ लोड/अनलोड करते रहते हैं। बहुत बड़ा हो तो हर चंक डाउनलोड होने में बहुत समय लेता है। आम ब्रॉडबैंड कनेक्शन वाले एक ब्राउज़र वर्ल्ड के लिए:

• ज़मीनी स्तर पर 64x64 मीटर चंक्स
• हर चंक में होता है: हाइटमैप पैच (2-4 KB), टेक्सचर स्प्लैट मैप (16-32 KB कम्प्रेस्ड), इंस्टैंस्ड रेफ़ के रूप में स्टैटिक मेश (1-50 KB इंस्टैंस डेटा), क्रिएटर द्वारा रखे गए ऑब्जेक्ट एक मेनिफ़ेस्ट के रूप में (1-10 KB)
• लोड रेडियस: पूरी डिटेल पर 5x5 चंक्स (320m दृश्य), मध्यम LOD पर 9x9, केवल-टेरेन पर 17x17
• लक्ष्य: हर चंक का पूरी-डिटेल डेटा 200 KB से कम, ताकि एक 5x5 मोहल्ला 5 MB से कम हो

प्रोग्रेसिव लोडिंग पाइपलाइन

एक चंक के बारे में सब कुछ एक साथ लोड न करें। एक प्रायोरिटी क्यू उपयोग करें:

1. पहले टेरेन ज्यामिति (केवल हाइटमैप, प्रति चंक 2-4 KB)। खिलाड़ी 100ms के भीतर ज़मीन देखता है।
2. टेरेन टेक्सचर (स्प्लैट मैप, पहले कम-रिज़ॉल्यूशन फिर अपग्रेड)। ज़मीन में 200ms के भीतर रंग आता है।
3. बड़ी संरचनाएँ (इमारतें, बड़ी चट्टानें)। सिल्हूट 500ms के भीतर दिखते हैं।
4. डिटेल ऑब्जेक्ट (फोलिएज, छोटे प्रॉप, क्रिएटर आइटम)। दुनिया 1-2 सेकंड में भरती है।
5. हाई-रेज़ टेक्सचर आख़िर में अपग्रेड होते हैं। अगर किसी दूर की इमारत के टेक्सचर को एक अतिरिक्त सेकंड लगे तो किसी को पता नहीं चलता।

यह इस बात से मेल खाता है कि मानव आँख कैसे काम करती है। हम लापता ज़मीन और लापता बड़ी संरचनाएँ नोटिस करते हैं। हम लापता घास नोटिस नहीं करते।

मेमोरी मैनेजमेंट

ब्राउज़र मेमोरी सीमित है और गार्बेज कलेक्टर आपका दुश्मन है। एक अकेला GC पॉज़ एक फ़्रेम के लिए आपको 60fps से 10fps तक गिरा सकता है।

ऑब्जेक्ट पूलिंग अनिवार्य है। आम ऑब्जेक्ट (पेड़, चट्टान, घास के पैच) के लिए पूल पहले से आवंटित करें और चंक्स के लोड/अनलोड होने पर उन्हें रीसायकल करें। हॉट पाथ में कभी नए THREE.Mesh या BABYLON.Mesh इंस्टैंस न बनाएँ। इसके बजाय पूल किए गए ऑब्जेक्ट पर ज्यामिति और मटेरियल रेफ़रेंस स्वैप करें।

टेक्सचर एटलस ड्रॉ कॉल और मेमोरी फ़्रैगमेंटेशन दोनों कम करते हैं। सभी टेरेन टेक्सचर को कुछ बड़े एटलस में पैक करें। क्रिएटर-अपलोडेड टेक्सचर को सर्वर पर प्रति-चंक एटलस में पैक करें और उन्हें एकल छवियों के रूप में स्ट्रीम करें।

ज्यामिति कम्प्रेशन Draco या Meshopt के साथ डाउनलोड आकार को 5-10x कम करता है और डीकम्प्रेशन एक Web Worker पर चलता है ताकि यह मेन थ्रेड को ब्लॉक न करे। खासकर टेरेन के लिए, क्वांटाइज़ किए गए हाइटमैप (सरल डेल्टा एन्कोडिंग के साथ कम्प्रेस्ड 16-बिट मान) किसी भी सामान्य-उद्देश्य मेश फ़ॉर्मेट से छोटे होते हैं।

ArrayBuffer ओनरशिप ट्रांसफ़र वर्कर और मेन थ्रेड के बीच कॉपी करने से बचाता है। जब एक वर्कर एक मेश डीकम्प्रेस करता है, तो ट्रांसफ़रेबल ऑब्जेक्ट के साथ postMessage का उपयोग करके बफ़र को बिना किसी कॉपी के मेन थ्रेड पर ट्रांसफ़र करें।

एसेट डिलीवरी

स्टैटिक वर्ल्ड डेटा के लिए एज कैशिंग के साथ CDN। टेरेन चंक्स, बेस मेश, और टेक्सचर एटलस जो अक्सर नहीं बदलते उन्हें आक्रामक रूप से कैश किया जाना चाहिए (Cache-Control: max-age=31536000, immutable)।

कंटेंट-एड्रेस्ड स्टोरेज का मतलब है हर एसेट वर्शन को उसके URL में एक अनोखा हैश मिलता है। जब कोई क्रिएटर एक चंक संशोधित करता है, तो नए वर्शन को नया हैश मिलता है और पुराना अब भी उसे देख रहे किसी के लिए कैश में रहता है। किसी कैश इनवैलिडेशन की ज़रूरत नहीं।

Basis Universal कम्प्रेशन के साथ KTX2 टेक्सचर। ये उस GPU फ़ॉर्मेट में डीकम्प्रेस होते हैं जो डिवाइस सपोर्ट करता है (BC7, ASTC, ETC2, या RGBA फ़ॉलबैक)। एक 1024x1024 टेरेन टेक्सचर अनकम्प्रेस्ड 4 MB से KTX2 में करीब 150 KB हो जाता है। हज़ारों अनोखे टेक्सचर वाली दुनिया के लिए, यह कम्प्रेशन ही व्यवहार्य और अव्यवहार्य के बीच का फ़र्क़ है।

सभी 3D एसेट के लिए glTF Binary (GLB)। यह 3D का JPEG है। हर ब्राउज़र इंजन इसे लोड करता है, यह कॉम्पैक्ट है, और यह एक ही फ़ाइल में टेक्सचर, मटेरियल, और एनिमेशन एम्बेड कर सकता है। मेश कम्प्रेशन के लिए Draco या Meshopt एक्सटेंशन उपयोग करें। क्रिएटर-अपलोडेड एसेट दुनिया में आने से पहले सर्वर-साइड पर ऑप्टिमाइज़्ड GLB में प्रोसेस होते हैं।

मल्टीप्लेयर नेटवर्किंग

सैकड़ों क्रिएटर्स को एक ही दुनिया में रखने के लिए एक ऐसा नेटवर्किंग आर्किटेक्चर चाहिए जो रियल-टाइम मूवमेंट, स्थायी वर्ल्ड स्टेट, और क्रिएटर एडिट को बिना पिघले संभाले।

सर्वर आर्किटेक्चर

वर्ल्ड स्टेट के लिए अथॉरिटेटिव सर्वर। ब्राउज़र अविश्वसनीय है। सभी सार्थक क्रियाएँ (ऑब्जेक्ट रखना, टेरेन संशोधित करना, चंक्स के बीच चलना) सर्वर-साइड पर सत्यापित होती हैं। क्लाइंट स्थानीय रूप से भविष्यवाणी करता है और सर्वर स्टेट के साथ मेल बैठाता है।

स्थानिक शार्डिंग दुनिया को सर्वर इंस्टैंस में बाँटती है। हर शार्ड वर्ल्ड ग्रिड के एक आयताकार क्षेत्र का मालिक होता है। जैसे-जैसे खिलाड़ी का घनत्व बदलता है, शार्ड बँट या मिल सकते हैं। EVE Online एक ही ब्रह्मांड में हज़ारों खिलाड़ियों को इसी तरह संभालता है, और छोटे पैमाने पर यही सिद्धांत है।

एक क्रिएटर वर्ल्ड के लिए जहाँ ज़्यादातर इंटरैक्शन स्थानीय होते हैं (आप अपने इलाके में बना रहे हैं, आपके पड़ोसी इसे देख सकते हैं), स्थानिक शार्डिंग स्वाभाविक रूप से काम करती है। एक शार्ड सीमा पर खड़ा खिलाड़ी दोनों शार्ड का कंटेंट देखता है, जिसके लिए क्रॉस-शार्ड विज़िबिलिटी क्वेरी चाहिए, लेकिन यह एक हल हो चुकी समस्या है।

सर्वर के लिए टेक्नोलॉजी विकल्प:

हमारा संदर्भ (Cloudflare इन्फ़्रास्ट्रक्चर): Durable Objects स्वाभाविक रूप से फ़िट होते हैं। हर वर्ल्ड चंक एक Durable Object बन जाता है जो उस चंक के कंटेंट के लिए अथॉरिटेटिव स्टेट रखता है। खिलाड़ी अपने मौजूदा चंक के लिए ज़िम्मेदार Durable Object से WebSocket के ज़रिए कनेक्ट होते हैं। जब वे किसी सटे हुए चंक में जाते हैं, तो वे उस चंक के DO से कनेक्ट होते हैं। Durable Objects स्टेट को अपने आप डिस्क पर स्थायी बनाते हैं, इसलिए वर्ल्ड डेटा रीस्टार्ट से बच जाता है।

क्लाइंट-सर्वर संचार

विश्वसनीय क्रमबद्ध संदेशों (चैट, वर्ल्ड एडिट, इन्वेंट्री, गेम स्टेट) के लिए WebSocket। खिलाड़ी जिस सक्रिय शार्ड को देख सकता है उसके प्रति एक कनेक्शन (आम तौर पर 1-4 कनेक्शन)।

अविश्वसनीय अक्रमबद्ध संदेशों (खिलाड़ी की स्थिति, एनिमेशन, क्षणिक प्रभाव) के लिए WebRTC DataChannel। WebRTC पीयर-टू-पीयर सक्षम है, लेकिन कई खिलाड़ियों वाली दुनिया के लिए, आप N2 कनेक्शन से बचने के लिए इसे एक SFU (Selective Forwarding Unit) के ज़रिए चलाएँगे। Cloudflare Calls या LiveKit SFU के रूप में काम कर सकते हैं।

स्टेट सिंक्रोनाइज़ेशन डेल्टा कम्प्रेशन उपयोग करता है। सर्वर ट्रैक करता है कि हर क्लाइंट ने क्या देखा है और केवल बदलाव भेजता है। एक क्रिएटर वर्ल्ड के लिए, यह खास तौर पर अहम है क्योंकि वर्ल्ड स्टेट (कौन से ऑब्जेक्ट मौजूद हैं, वे कहाँ हैं, उनके क्या गुण हैं) खिलाड़ी की स्थितियों से बहुत कम बार बदलता है। आप वर्ल्ड स्टेट अपडेट 2-5 Hz पर भेज सकते हैं जबकि खिलाड़ी की स्थितियाँ 20-30 Hz पर अपडेट होती हैं।

interface WorldChunkState {
  version: number;
  terrain: TerrainPatch;
  objects: PlacedObject[];
  creators: CreatorPresence[];
}

interface DeltaUpdate {
  chunkId: string;
  fromVersion: number;
  toVersion: number;
  addedObjects: PlacedObject[];
  removedObjectIds: string[];
  modifiedObjects: Partial<PlacedObject>[];
  creatorMoves: CreatorPosition[];
}