ویژول ناول تصویروں کا مجموعہ ہے۔ Builder اتنا پیچیدہ کیوں ہو گیا؟

پہلے version کا صرف ایک کام تھا

Romergo کا نام Romergo ہونے سے پہلے وہ Fibber تھا۔ وہ جڑے ہوئے مناظر سے ایک quest بناتا، مجھے ان میں متن اور تصاویر بھرنے دیتا اور شاخ دار انتخاب سنبھالتا تھا۔ Stack میں TypeScript، React، Strapi اور Ant Design شامل تھے۔

اس version نے اپنا کام کیا۔ Flow graph نے کہانی کو دکھائی دینے کے قابل بنایا، مناظر edit ہو سکتے تھے اور نتیجہ preview کیا جا سکتا تھا۔ Prototype کے لیے یہ کافی تھا۔ اصل مسئلہ دکھانے کے لیے بھی کافی تھا۔

پہلی اصل رکاوٹ code نہیں تھی

جب ہم نے ایک حقیقی quest میں متن اور تصاویر بھرنا شروع کیا تو دس منٹ کا منظر بنانے میں تقریباً پورا دن لگ سکتا تھا۔ منظر بنائیں۔ پس منظر upload کریں۔ کردار upload کریں۔ انہیں رکھیں۔ مکالمہ شامل کریں۔ اگلا منظر جوڑیں۔ پھر دہرائیں۔

اس کا کچھ حصہ interface کا مسئلہ تھا۔ میں نے UX بہتر کیا، uploads تیز کیے اور publishing کو زیادہ قابل اعتماد بنایا۔ لیکن سب سے بڑی لاگت وہی رہی: ہر چھوٹا کام اب بھی کسی انسان کو ہاتھ سے کرنا پڑتا تھا۔

اگر دو لوگ ایک ہی وقت میں بنا سکیں تو؟

پہلا جواب سادہ تھا: اگر ایک شخص bottleneck ہے تو کئی لوگوں کو ایک ہی کہانی پر کام کرنے دیں۔ میں نے Liveblocks سے آغاز کیا، اس model سے سیکھا اور بعد میں Yjs کو مرکز بنا کر اپنی collaboration layer کی طرف بڑھا۔

نیچے کا تجربہ دو editor windows کو ایک ساتھ بدلتے ہوئے دکھاتا ہے۔ اس کے نیچے product کی سوچ میں کہیں بڑی تبدیلی ہے: edits الگ الگ form submissions کے بجائے shared document کی updates بن جاتی ہیں۔ یہیں سے presence، reconnects، conflict handling، permissions اور project کے ہمیشہ زندہ رہنے کی توقع آتی ہے۔

ہر مفید shortcut آخرکار ایک حد بن گیا

Strapi تیزی سے backend حاصل کرنے کا بہترین طریقہ تھا، لیکن کہانی کی ہر نئی مخصوص feature CMS سے تھوڑا کم CMS جیسا برتاؤ مانگتی تھی۔ Ant Design نے پہلے interface کو رفتار اور consistency دی، پھر آہستہ آہستہ product کو کسی اور کے visual system تک محدود کر دیا۔

بعد کی Remix-based serverless iteration ایک اہم قدم تھی۔ پھر بھی application، media اور deployment کو جوڑنے کے میرے طریقے نے وہ horizontal آزادی نہیں دی جس کی product کو ضرورت ہونے لگی تھی۔ ان میں سے کوئی فیصلہ غلط نہیں تھا۔ ہر ایک نے اگلی حد دریافت کرنے کے لیے کافی وقت دیا۔

تصاویر attachments نہیں ہیں۔ یہ infrastructure ہیں۔

Media خود ایک الگ سبق بن گیا۔ کہانی کی تصویر ایک بار upload ہو، ضرورت پر تبدیل ہو، محفوظ رکھی جائے اور دنیا کے کسی بھی player تک تیزی سے پہنچے۔ اسے بڑھتے application server کے ساتھ رکھنے سے backend مزید بھاری ہوا، اس لیے پہلا الگ حل Cloudinary تھا۔

ایک شام dashboard کھولا تو دیکھا کہ ایک user نے وہی تصویر سینکڑوں بار upload کر کے تقریباً 500 MB خرچ کیے۔ میرے ہنگامی fix نے image hashes ملا کر duplicates رد کیے۔ یہ چلا، مگر rate limits اور quotas اس رویے کو زیادہ براہ راست روکتے۔ بڑا تعجب bandwidth تھا: ایک شام کی testing مفت allowance کا دس فیصد سے زیادہ کھا سکتی تھی۔

اس واقعے نے model بدل دیا۔ Media اب scene کا ایک field نہیں رہ سکتا تھا۔ اسے storage، deduplication، delivery، caching اور access کی اپنی pipeline چاہیے تھی۔

آج وہ سادہ خیال کیسا دکھتا ہے

موجودہ Romergo، Builder کو player سے الگ رکھتا ہے، لیکن دونوں ایک ہی story runtime استعمال کرتے ہیں۔ Editor کا preview اور published playthrough ایک ہی اصولوں پر چلتے ہیں، اس لیے contract drift پیدا کرنا بہت مشکل ہے۔

Yjs قابل ترمیم project کو collaborators کے درمیان sync کرتا ہے۔ Publishing، story data اور media کا checked snapshot بناتی ہے، اس لیے creators اس version کو خاموشی سے بدلے بغیر draft پر کام جاری رکھ سکتے ہیں جسے players پہلے چلا رہے ہیں۔ API، Hono سے بنی ہے، interface میں shadcn اور Radix primitives ہیں، اور cloud layer distributed coordination، object storage اور CDN delivery دیتی ہے۔

یہ shared runtime اب کہانی کو browser اور PWA، Telegram اور synchronized Discord experience تک لے جاتا ہے۔ Version compatibility، offline behavior اور multiplayer state اب page کے اردگرد side effects نہیں، بلکہ اپنے product systems ہیں۔

موجودہ architecture

ایک قابل ترمیم کہانی۔ ایک published contract۔

Romergo کی موجودہ architecture کا عمومی خاکہ۔

1. قابل ترمیم project

• Builder UI: مناظر · flow · media
• AI / MCP: تصدیق شدہ editing operations
• Realtime / Yjs: Durable Objects · shared working document
• Editor API: CAS writes · draft materialization
• Draft runtime snapshot: PublishedQuestLocalizedContentV2 · D1 / R2
• Draft media: R2 objects · D1 metadata

2. Versioned publishing

• Publishing checks: Runtime schema · مصنف کی تصدیق · media کی موجودگی
• ناقابل تبدیلی publication vN: Runtime snapshot · copy اور remap کیا media
• Visibility contract: Public · unlisted · private

3. ایک execution contract

• Draft snapshot: تازہ ترین قابل ترمیم حالت
• Publication vN: مستحکم player state
• Shared player-runtime: مناظر · transitions · conditions · variables · saves
• Builder preview: اسی engine میں draft چلاتا ہے

4. Playback channels

• Web / PWA: Browser player
• Telegram Mini App: Embedded player
• Discord Activity: Synchronized group play

5. Platform infrastructure

• Clerk + OAuth: شناخت اور MCP access
• Hono Workers: API اور MCP services
• Cloudflare D1: Projects · versions · metadata
• Cloudflare R2: Media · بڑے runtime snapshots
• Durable Objects: Yjs rooms · Discord sessions
• Player progress: D1 sync · local offline queue

ناول اب بھی صرف تصاویر ہی ہے

دلچسپ بات یہ ہے کہ ابتدائی خیال باقی رہا۔ ویژول ناول اب بھی پس منظر، کردار، متن، انتخاب اور آواز ہے۔ Romergo اس لیے پیچیدہ ہوا کہ اس سادہ مرکز کے اردگرد ہر چیز کو قابل اعتماد بننا تھا: collaboration، media، publishing، versioning، offline play اور ایک ہی کہانی کا تجربہ کرنے کے کئی طریقے۔

اس ارتقا نے مجھے ایک بات سکھائی ہے: صرف آخری screen دکھانے والے code کو نہیں، انسان کے پورے راستے کو ناپو۔ Player کو شاید پانچ بنیادی چیزیں درکار ہوں۔ کسی خیال کو مکمل، قابل کھیل کہانی میں بدلنے میں مدد دینے والے product کو ایک system چاہیے۔