पोर्टेबिलिटी

आयात और निर्यात: कहानी आपकी ही रहनी चाहिए

यह एक और कहानी है कि मुझे browser और web इतने पसंद क्यों हैं। इनके तेज़ विकास की वजह से 2026 में एक ही कहानी browser, offline archive, Windows और macOS app में चल सकती है, और इसके लिए कई अलग-अलग game engines बनाने की जरूरत नहीं।

अगस्त 2026 में import और export शुरू होने से पहले Romergo में लंबे समय से vendor lock-in की समस्या थी: उपयोगकर्ता सिस्टम के अंदर कुछ बना सकता था, लेकिन अपना पूरा काम आसानी से साथ नहीं ले जा सकता था। अब ऐसा नहीं है। Project owner दस्तावेज़ीकृत .romergo archive डाउनलोड कर सकता है या web, Windows, macOS और Microsoft Store के लिए standalone game तैयार कर सकता है। लेखक कभी Romergo छोड़ भी दे, तब भी उसका project उसी का रहना चाहिए।

इसीलिए मैंने import और export पर काम शुरू किया।

Web ने यह काम इतना छोटा कैसे किया

Romergo में पहले से एक साझा Player runtime था। वह scenes, branches, images, music, video, translations, RTL languages और local saves चला सकता है। आम तौर पर वह published story को service से लोड करता है, लेकिन उसे कहानी के साथ pack करके network पूरी तरह बंद भी किया जा सकता है।

Web build ZIP की root में index.html रखती है। Windows और macOS उसी Player को सुरक्षित Electron shell में pack करते हैं। Microsoft Store को वही game MSIXUpload में मिलता है। कहानी की logic चार बार नहीं लिखी जाती; केवल एक runtime के चारों ओर packaging बदलती है।

Platform signing, certificates, notarization, store rules और developer accounts फिर भी चाहिए। लेकिन सबसे महँगा हिस्सा अब दोहराना नहीं पड़ता: हर platform के लिए अलग client और अलग व्यवहार।

Export कैसे काम करता है

Romergo editor की कोई अधूरी या संयोगवश बनी state copy नहीं करता। वह Saved draft या publication का चुना हुआ saved version लेता है। Runtime और assets को revisions पर pin किया जाता है। Build के बीच project बदल जाए तो job दोबारा चलती है; पुराने scenes को नए files के साथ मिलाया नहीं जाता।

पहला परिणाम हमेशा .romergo होता है: documented structure वाला सामान्य ZIP। इसमें manifest, project, chapters, scenes, flow graph, variables, presentation, media, credits और SHA-256 checksums होते हैं। Archive contributors के दिखने वाले नाम और roles रखता है, लेकिन email या internal IDs नहीं।

saved draft या publication
        ↓
consistent runtime और asset revisions
        ↓
documented .romergo archive
        ↓
isolated platform builder
        ↓
7 दिनों के लिए private ZIP या MSIXUpload

हर asset को पढ़कर hash किया जाता है और लिखने से पहले फिर जाँचा जाता है। Archive stream होकर सीधे private R2 में जाती है, इसलिए Worker को कई GB का project memory में नहीं रखना पड़ता।

Editable project चाहिए तो प्रक्रिया यहीं खत्म होती है। Game build के लिए .romergo internet access से अलग Linux container में जाती है। Container archive validate करता है, offline Player जोड़ता है और इनमें से एक output बनाता है:

Romergo Steam credentials, Apple Developer ID, certificates या passwords नहीं माँगता। Signing और publishing लेखक के अपने accounts में रहती है। Service upload-ready build बनाती है, उसे सात दिन private रखती है और owner को short-lived download link देती है।

कीमत ने मुझे भी चौंकाया। Production की “Blizzard” कहानी में लगभग 30 MB के 101 media files हैं। Cloudflare में शामिल resources खत्म होने के बाद भी मौजूदा rates पर उसका platform export केवल कुछ cents का पड़ता है। सबसे बड़ा खर्च R2 या traffic नहीं, packaging खत्म होने के बाद container का जीवित समय है।

आप browser में “The Blizzard” का production version खेल सकते हैं। यही project इस लागत माप के लिए इस्तेमाल हुआ था।

Import कहीं अधिक कठिन था

Visual novel editors और engines की संख्या दस से अधिक है। कोई Twine, ink, Yarn Spinner या Ren’Py लाता है; कोई Notepad, Obsidian या Notion में लिखता है; और कोई PDF, Markdown, spreadsheet, voice notes, video links तथा images का folder देता है।

Formats हजारों हैं और हर साल बदलते हैं। हर format के लिए native importer लिखने पर पाँच साल बाद पुराने third-party versions समझने वाले parsers का कब्रिस्तान बन जाएगा।

उत्तर पहले से मेरे पास था: AI agents।

Agent को HTML, Markdown, PDF, audio, images और links दिए जा सकते हैं। वह क्रम समझ सकता है, बार-बार आने वाले characters पहचान सकता है, अस्पष्ट branches दिखा सकता है और लेखक से सवाल पूछ सकता है। मनुष्य flow को दिशा देता है और result जाँचता है।

Romergo में MCP support पहले से थी। इसलिए Romergo को दुनिया के हर format की शिक्षा देने के बजाय मैंने एक स्थिर लक्ष्य रखा: वे tools जिनसे agent सामान्य Romergo project बनाता और verify करता है।

Agent के जरिए import flow

source files और links
        ↓
user का MCP-capable agent
        ↓
inventory, preview, questions और warnings
        ↓
Romergo MCP authoring tools
        ↓
persisted readback और project validation
        ↓
Builder में creator की जाँच

पहले user अपने MCP-compatible agent को जोड़ता है और source materials देता है। Agent chapters, scenes, characters, locations, media, languages और links की inventory बनाता है। HTML, Markdown, TXT और text-based PDF के लिए romergo_inspect_story_source और romergo_import_story_source बिना काल्पनिक branches बनाए literal linear migration कर सकते हैं।

Twine, ink, Yarn Spinner और Ren’Py में passages, knots, nodes, dialogue, choices और basic variables आम तौर पर chapters, scenes और transitions बनते हैं। Macros, Python, Unity commands, screens, CSS/JS और external functions warnings में जाते हैं और मनुष्य का निर्णय माँगते हैं।

Preview के बाद agent नया project बनाता है, attachments batch में upload करता है और graph तथा scenes लिखता है। बड़े media files one-time upload से सीधे R2 में जाते हैं। फिर agent romergo_get_chapter से saved data दोबारा पढ़ता है, romergo_validate_project चलाता है और romergo_verify_quest_change सफल होने पर ही migration पूरा मानता है।

AI जाँच की जगह नहीं लेता

Agent अर्थ समझ सकता है, लेकिन अनुमान तथ्य नहीं बन जाता। Audio को external transcription चाहिए हो सकता है, video link उपयोग का अधिकार नहीं देता, और complex Ren’Py code या Twine macro अपने आप में program हो सकता है। इसलिए import flow preview और warnings दिखाता है तथा project बनाने से पहले material rights की पुष्टि माँगता है।

Romergo का native uploader केवल .romergo स्वीकार करता है। यह जानबूझकर है: अपने खुले format का import deterministic और सुरक्षित होना चाहिए; बाहरी sources की अनंत दुनिया को reasoning और सवाल पूछ सकने वाले tool से समझना बेहतर है।

अगले पाँच वर्षों के लिए दाँव

Formats बदलेंगे, models और agents भी बदलेंगे। लेकिन सीमा स्थिर रह सकती है: एक ओर किसी भी तरह की मानवीय रचना, दूसरी ओर documented .romergo और MCP authoring tools।

कल कोई नया लोकप्रिय editor आए तो Romergo को अलग importer का इंतज़ार नहीं करना होगा। Agent उसकी files पढ़ सकता है, अपनी समझ दिखा सकता है और उसी contract से result लिख सकता है। लेखक Romergo छोड़ दे तो उसके पास open archive और autonomous game फिर भी रहेंगे।

मेरे लिए सही दिशा यही है: Romergo कहानियाँ बनाने की सुविधाजनक जगह हो, ऐसी कैद नहीं जहाँ से उन्हें बाहर न ले जाया जा सके।

डेव ब्लॉग पर वापस जाएँ