AI-native game engines शिप हो रहे हैं, और वे Unity जैसे बिल्कुल नहीं दिखते
Oleg Sidorkin द्वारा, Cinevva के CTO
मार्च में तीन game engines सामने आए जो architecture के लिहाज़ से Unity/Unreal/Godot की पूरी वंशावली से अलग हैं। इनमें visual editor नहीं हैं। ये किसी इंसान के menus पर click करते जाने के लिए optimize नहीं किए गए हैं। ये शुरू से ही इस तरह बने हैं कि AI agents game state को पढ़ें, लिखें और control करें।
यह "AI tab वाला Unity" नहीं है। यह engine की एक अलग ही प्रजाति है।
AI पहले से ही 3D game development के workflows बदल रहा है। अब बारी engine layer की है।
तीनों engines
nAIVE Engine open-source है, Rust में लिखा गया है और WebGPU rendering के साथ आता है। एक सेकंड से कम का hot-reload: shaders 200ms से कम में, scenes 100ms से कम में, scripts 50ms से कम में। Scenes, pipelines और materials YAML में define किए जाते हैं, जिसका मतलब है कि LLMs उन्हें binary formats parse किए बिना पढ़ और generate कर सकते हैं। यह एक MCP command interface देता है जिससे AI agents JSON-RPC के ज़रिए engine functions को control कर सकते हैं। इसके साथ first-class Gaussian splatting और automated testing के लिए headless rendering आता है। पूरा architecture यह मानकर चलता है कि आपका primary user एक AI agent हो सकता है, mouse वाला कोई इंसान नहीं।
Arcane Engine एक code-first 2D engine है। Rust core, TypeScript scripting। visual editor बिल्कुल नहीं। इसका दर्शन है: "code ही scene है।" Game state एक scene tree के बजाय एक queryable database है। इसमें AI agent interaction के लिए एक built-in protocol शामिल है। Apache 2.0 licensed।
Mirror Engine alpha में है, और यह एक entity component system के साथ multiplayer-first है। दिलचस्प बात यह है: इसमें AI text-to-3D generation शामिल है जो text prompts से करीब 60 सेकंड में Gaussian splats बनाता है। TypeScript scripting, browser-आधारित "Mirror Lite" client।
ये तीनों engines न एक codebase साझा करते हैं न एक team, लेकिन इनकी design thesis एक ही है: किसी game engine का primary interface एक GUI नहीं, structured text होना चाहिए।
यह architecture क्यों मायने रखता है
पारंपरिक game engines एक desk पर बैठे इंसान की सेवा के लिए विकसित हुए। आपके पास एक viewport होता है। एक hierarchy panel। एक inspector। एक timeline। सब कुछ clicking, dragging और objects को visually रखने के इर्द-गिर्द design किया गया है। वह workflow ताक़तवर है। और यह एक AI agent के लिए इस्तेमाल करना नामुमकिन भी है।
जब आपका primary "user" एक LLM हो, तो आपको अलग primitives चाहिए। binary scene formats के बजाय YAML। nested scene trees के बजाय queryable state। mouse clicks के बजाय protocol-आधारित commands। window rendering के बजाय headless operation।
यह वही बदलाव है जो infrastructure में तब हुआ था जब DevOps GUI control panels से infrastructure-as-code की ओर बढ़ा। यही चीज़ अब game engines में हो रही है, बस बीस साल बाद।
nAIVE का MCP interface इसका सबसे साफ़ उदाहरण है। MCP (Model Context Protocol) तेज़ी से वह standard तरीका बनता जा रहा है जिससे AI agents tools के साथ बात करते हैं। जब कोई engine MCP को natively बोलता है, तो इस protocol को support करने वाला कोई भी AI agent scenes को बदल सकता है, parameters adjust कर सकता है, tests चला सकता है और बिना किसी इंसान के बीच में आए gameplay पर iterate कर सकता है। यह किसी पारंपरिक engine में ऊपर से जोड़ा गया feature नहीं है। यह engine और उसके user के बीच एक मौलिक रूप से अलग रिश्ता है।
Game development में Gaussian splatting। nAIVE और Mirror दोनों इसे एक first-class rendering primitive मानते हैं।
बड़ी तस्वीर
ये तीन engines अकेला signal नहीं हैं। Meshy के Black Box ने runtime पर AI-generated game mechanics दिखाए। OpenAI ने GDC में Phaser से बना एक tactical RPG दिखाया। "AI कुछ generate करता है" और "वह कुछ एक playable game की तरह चलता है" के बीच की tooling layer हर महीने पतली होती जा रही है।
Cinevva में, हम इस पुल को दूसरी दिशा से बना रहे हैं। हमारा engine rendering, physics और real-time interaction संभालता है जबकि AI asset generation संभालता है। यह तरीका nAIVE या Arcane से अलग है, लेकिन इसके पीछे का दांव वही है: भविष्य के game engine को AI को एक plugin की तरह जोड़ने के बजाय उसे पहली भाषा की तरह बोलना होगा।
पारंपरिक engine बनाने वाले भी यह जानते हैं। Unity ने GDC में AI game creation tools की झलक दिखाई। Roblox ने AI-powered 4D model creation launch किया। लेकिन इंसानों के लिए design किए गए engine में AI features जोड़ने और ऐसा engine design करने में, जहाँ AI ही primary interface हो, एक बड़ा फ़र्क़ है।
मेरे हिसाब से आगे क्या होगा
इनमें से ज़्यादातर engines टिकेंगे नहीं। किसी नई category के लिए यह सामान्य है। लेकिन design patterns टिकेंगे। YAML-आधारित scene definitions, agent control के लिए MCP protocols, queryable game state, headless operation। ये विचार दो साल के भीतर mainstream engines में समा जाएंगे।
इस दौर को जीतने वाला engine शायद अभी मौजूद ही नहीं है। लेकिन architectural DNA अभी इसी वक़्त लिखा जा रहा है, इन तीन projects में और कुछ और में। सवाल यह नहीं है कि game engines AI-native बनेंगे या नहीं। सवाल यह है कि यह बदलाव मौजूदा बड़ी कंपनियों के अंदर से आएगा या उन नए खिलाड़ियों से जिन्होंने पहले दिन से agents के लिए design किया।
संबंधित:
- अब हर कोई AI game engine बनना चाहता है — वह platform दौड़ जिसने मंच तैयार किया
- Frontier Open-Source Gen AI Models — वे models जिन्हें ये engines integrate कर रहे हैं
- Web Game Engines Comparison — नए engines बड़े ecosystem में कहाँ फ़िट होते हैं
- Open source में AI pollution की समस्या है — AI-generated contributions की लागत वाला पहलू