قابلية النقل

الاستيراد والتصدير: يجب أن تبقى القصة ملكًا لك

هذه حكاية أخرى عن سبب حبي للمتصفحات والويب عمومًا. فبفضل تطورهما السريع، أصبح من الممكن في 2026 تشغيل القصة نفسها في المتصفح، وفي حزمة مستقلة، وفي تطبيقات Windows وmacOS من دون بناء عدة محركات ألعاب منفصلة.

قبل إطلاق الاستيراد والتصدير في أغسطس 2026، ظلّت في Romergo مشكلة vendor lock-in مدة طويلة: كان المستخدم يبدع داخل النظام، لكنه لم يكن يستطيع أخذ عمله كاملًا بسهولة. لم يعد الأمر كذلك الآن. يستطيع مالك المشروع تنزيل أرشيف .romergo موثق أو تجهيز لعبة مستقلة للويب وWindows وmacOS وMicrosoft Store. يجب أن يبقى المشروع ملكًا لمؤلفه حتى لو قرر يومًا مغادرة Romergo.

لهذا بدأت العمل على الاستيراد والتصدير.

كيف جعل الويب المهمة أصغر بكثير

كان لدى Romergo بالفعل Player runtime مشترك يدعم المشاهد والتفرعات والصور والموسيقى والفيديو والترجمات ولغات RTL والحفظ المحلي. عادةً يحمّل القصة المنشورة من الخدمة، لكن يمكن أيضًا حزمه مع القصة وتعطيل الشبكة بالكامل.

تضع نسخة الويب ملف index.html في جذر ZIP. ويغلّف Windows وmacOS الـPlayer نفسه داخل غلاف Electron مؤمّن. أما Microsoft Store فيحصل على اللعبة نفسها داخل MSIXUpload. لا نعيد كتابة منطق القصة أربع مرات؛ الذي يتغير هو التغليف حول runtime واحد.

لا تزال التواقيع والشهادات وnotarization وقواعد المتاجر وحسابات المطورين مطلوبة. لكن الجزء الأغلى، أي تطوير عميل منفصل بسلوك مختلف لكل منصة، لم يعد يتكرر.

كيف يعمل التصدير

لا ينسخ Romergo حالة عشوائية أو غير مكتملة من المحرر. بل يأخذ مسودة في حالة Saved أو نسخة منشورة محفوظة بعينها. تُثبَّت إصدارات runtime والملفات؛ وإذا تغير المشروع أثناء البناء، تُعاد المهمة بدل خلط مشاهد قديمة بملفات جديدة.

النتيجة الأولى دائمًا هي .romergo: ملف ZIP عادي ببنية موثقة. يحتوي على manifest والمشروع والفصول والمشاهد ومخطط التدفق والمتغيرات والعرض والوسائط وcredits وSHA-256 checksums. يحتفظ الأرشيف بالأسماء الظاهرة وأدوار المساهمين، لا بعناوين البريد أو المعرّفات الداخلية.

مسودة محفوظة أو نسخة منشورة
        ↓
إصدارات متسقة للـ runtime والملفات
        ↓
أرشيف .romergo موثق
        ↓
منشئ منصات معزول
        ↓
ZIP أو MSIXUpload خاص لمدة 7 أيام

يُقرأ كل ملف ويُحسب hash له ثم يُفحص مرة أخرى قبل الكتابة. يُبنى الأرشيف بشكل متدفق ويذهب مباشرة إلى R2 خاص، فلا يحتاج Worker إلى الاحتفاظ بمشروع حجمه عدة غيغابايت في الذاكرة.

إذا أراد المستخدم مشروعًا قابلًا للتحرير تنتهي العملية هنا. أما بناء اللعبة فيرسل .romergo إلى حاوية Linux معزولة بلا اتصال بالإنترنت. تتحقق الحاوية من الأرشيف، وتضيف Player مستقلًا، ثم تنتج أحد الخيارات التالية:

• Web / itch.io ZIP وفي جذره index.html؛
• Windows x64 ZIP مع حفظ محلي وقالب SteamPipe وsigning kit محلي؛
• macOS ZIP بتطبيقين منفصلين لـApple Silicon وIntel؛
• MSIXUpload بهوية حصل عليها المستخدم من Microsoft Partner Center.

لا يطلب Romergo بيانات Steam أو Apple Developer ID أو الشهادات أو كلمات المرور. يبقى التوقيع والنشر داخل حسابات المؤلف. تجهز الخدمة build قابلًا للرفع، وتحفظه بشكل خاص سبعة أيام، وتمنح المالك رابط تنزيل قصير العمر.

وقد فاجأتني التكلفة أيضًا. تضم قصة “Blizzard” على production عدد 101 ملف وسائط بحجم يقارب 30 MB. حتى بعد استنفاد الموارد المشمولة، لا يكلف تصديرها بالأسعار الحالية لـCloudflare سوى بضعة سنتات. التكلفة الأساسية ليست R2 ولا نقل البيانات، بل مدة بقاء الحاوية بعد انتهاء التغليف.

يمكنك لعب نسخة الإنتاج من “Blizzard” في المتصفح، وهي المشروع نفسه الذي استُخدم في هذا القياس.

الاستيراد كان أصعب

هناك أكثر من عشرة محررات ومحركات للروايات المرئية. يأتي مؤلفون من Twine وink وYarn Spinner وRen’Py، ويكتب آخرون في المفكرة أو Obsidian أو Notion. وقد تكون المواد PDF أو Markdown أو جداول أو تسجيلات صوتية أو روابط فيديو أو مجلدات صور.

التنسيقات بالآلاف، وتظهر وتختفي كل عام. لو كتبنا importer أصليًا لكل تنسيق، فسنحصل بعد خمس سنوات على مقبرة من parsers لا يفهم كل منها إلا نسخة قديمة من منتج آخر.

كانت الإجابة موجودة بالفعل: وكلاء AI.

يمكن إعطاء الوكيل HTML وMarkdown وPDF وصوتًا وصورًا وروابط. يستطيع استعادة التسلسل، والعثور على الشخصيات المتكررة، ووضع علامة على التفرعات الغامضة، وطرح أسئلة على المؤلف. يوجّه الإنسان العملية ويراجع النتيجة.

كان Romergo يدعم MCP مسبقًا. لذلك، بدل تعليم المنتج كل تنسيقات العالم، أبقيت هدفًا ثابتًا: أدوات يستخدمها الوكيل لإنشاء مشروع Romergo عادي والتحقق منه.

مسار الاستيراد عبر الوكيل

الملفات والروابط الأصلية
        ↓
وكيل المستخدم المتوافق مع MCP
        ↓
جرد ومعاينة وأسئلة وتحذيرات
        ↓
أدوات التأليف في Romergo MCP
        ↓
إعادة قراءة البيانات والتحقق من المشروع
        ↓
مراجعة المؤلف للنتيجة في Builder

يوصل المستخدم وكيله المتوافق مع MCP ويعطيه المصادر. ينشئ الوكيل جردًا للفصول والمشاهد والشخصيات والأماكن والوسائط واللغات والعلاقات. بالنسبة إلى HTML وMarkdown وTXT وملفات PDF النصية، تستطيع الأداتان romergo_inspect_story_source وromergo_import_story_source إجراء نقل خطي حرفي من دون اختراع تفرعات.

في Twine وink وYarn Spinner وRen’Py تتحول passages وknots وnodes والحوارات والخيارات والمتغيرات الأساسية عادةً إلى فصول ومشاهد وانتقالات. أما macros وPython وأوامر Unity وscreens وCSS/JS والدوال الخارجية فتظهر في warnings وتحتاج إلى قرار بشري.

بعد المعاينة، ينشئ الوكيل مشروعًا جديدًا، ويرفع المرفقات دفعة واحدة، ويكتب المخطط والمشاهد. تذهب الوسائط الكبيرة مباشرة إلى R2 عبر رفع يستخدم مرة واحدة. ثم يعيد الوكيل قراءة البيانات المحفوظة بواسطة romergo_get_chapter، ويشغّل romergo_validate_project، ولا يعتبر النقل مكتملًا إلا بعد نجاح romergo_verify_quest_change.

الذكاء الاصطناعي لا يلغي المراجعة

يفهم الوكيل المعنى، لكن التخمين لا يصبح حقيقة. قد يحتاج الصوت إلى تفريغ خارجي، ولا يمنح رابط الفيديو حق استخدامه، وقد يكون Ren’Py code أو Twine macro المعقد برنامجًا مستقلًا. لذلك يعرض مسار الاستيراد preview وwarnings ويطلب تأكيد حقوق المواد قبل إنشاء المشروع.

يقبل المستورد الأصلي في Romergo ملفات .romergo فقط. هذا مقصود: يجب استيراد تنسيقنا المفتوح بصورة حتمية وآمنة، بينما من الأفضل فهم عالم المصادر الخارجية المفتوح بأداة تستطيع الاستدلال وطرح الأسئلة.

رهان السنوات الخمس القادمة

ستتغير التنسيقات والنماذج والوكلاء، لكن الحد الفاصل يمكن أن يبقى ثابتًا: مواد البشر بأي شكل من جهة، و.romergo الموثق وأدوات MCP من جهة أخرى.

إذا ظهر محرر شائع جديد، فلن يحتاج Romergo إلى انتظار importer خاص. يستطيع الوكيل دراسة ملفاته وإظهار ما فهمه وكتابة النتيجة عبر العقد نفسه. وإذا غادر المؤلف Romergo، فسيظل لديه أرشيف مفتوح ولعبة مستقلة.

هذا هو الاتجاه الصحيح بالنسبة إليّ: يجب أن يكون Romergo مكانًا مريحًا لصناعة القصص، لا قفصًا يستحيل إخراجها منه.

العودة إلى مدونة التطوير