منتقلی

امپورٹ اور ایکسپورٹ: کہانی آپ ہی کی رہنی چاہیے

یہ ایک اور قصہ ہے کہ مجھے browsers اور web اتنے پسند کیوں ہیں۔ ان کی تیز رفتار ترقی کی بدولت 2026 میں ایک ہی کہانی browser، offline archive، Windows اور macOS app میں چل سکتی ہے، اور اس کے لیے کئی الگ game engines بنانے کی ضرورت نہیں۔

اگست 2026 میں import اور export شروع ہونے سے پہلے Romergo میں طویل عرصے سے vendor lock-in کا مسئلہ تھا: صارف system کے اندر کچھ تخلیق تو کر سکتا تھا، مگر اپنا مکمل کام آسانی سے ساتھ نہیں لے جا سکتا تھا۔ اب ایسا نہیں ہے۔ Project owner دستاویزی .romergo archive download کر سکتا ہے یا 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 سے load کرتا ہے، مگر اسے کہانی کے ساتھ 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 اور الگ behavior۔

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 کیا جاتا ہے اور لکھنے سے پہلے دوبارہ verify کیا جاتا ہے۔ Archive stream ہو کر براہ راست private R2 میں جاتی ہے، اس لیے Worker کو کئی GB کا project memory میں رکھنے کی ضرورت نہیں۔

Editable project مطلوب ہو تو عمل یہیں مکمل ہو جاتا ہے۔ Game build کے لیے .romergo ایک isolated Linux container میں جاتی ہے جسے internet access نہیں۔ 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 میں “Blizzard” کا production version کھیل سکتے ہیں۔ اسی project کو اس لاگت کے حساب میں استعمال کیا گیا تھا۔

Import زیادہ مشکل تھا

Visual novel editors اور engines کی تعداد دس سے زیادہ ہے۔ کوئی Twine، ink، Yarn Spinner یا Ren’Py سے آتا ہے؛ کوئی Notepad، Obsidian یا Notion میں لکھتا ہے؛ اور کوئی PDF، Markdown، spreadsheets، 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 پہلے سے موجود تھی۔ اس لیے دنیا کے تمام formats Romergo کو سکھانے کے بجائے میں نے ایک مستحکم ہدف رکھا: وہ 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 کی review

پہلے user اپنے MCP-compatible agent کو connect کر کے source materials دیتا ہے۔ Agent chapters، scenes، characters، locations، media، languages اور relations کی 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 استعمال کا حق نہیں دیتا، اور پیچیدہ Ren’Py code یا Twine macro بذات خود ایک program ہو سکتا ہے۔ اسی لیے import flow preview اور warnings دکھاتا اور project بنانے سے پہلے materials کے rights کی تصدیق مانگتا ہے۔

Romergo کا native uploader صرف .romergo قبول کرتا ہے۔ یہ دانستہ ہے: اپنے open format کا import deterministic اور محفوظ ہونا چاہیے؛ بیرونی sources کی لامحدود دنیا کو reasoning اور سوال کرنے والے tool سے سمجھنا بہتر ہے۔

اگلے پانچ سال کی سمت

Formats بدلیں گے، models اور agents بھی بدلیں گے۔ مگر boundary مستحکم رہ سکتی ہے: ایک طرف کسی بھی شکل میں انسانی مواد، دوسری طرف documented .romergo اور MCP authoring tools۔

اگر مستقبل میں کوئی نیا مقبول editor آئے تو Romergo کو الگ importer کا انتظار نہیں کرنا پڑے گا۔ Agent اس کی files پڑھ کر اپنی سمجھ دکھا اور اسی contract سے result لکھ سکے گا۔ اور اگر مصنف Romergo چھوڑ دے تو اس کے پاس open archive اور autonomous game پھر بھی موجود ہوں گے۔

میرے نزدیک درست سمت یہی ہے: Romergo کہانیاں بنانے کی آسان جگہ ہو، ایسا پنجرہ نہیں جہاں سے انہیں باہر نہ لے جایا جا سکے۔

ڈیولپمنٹ بلاگ پر واپس جائیں