ניידות

ייבוא וייצוא: הסיפור צריך להישאר שלכם

זה עוד סיפור על הסיבה לכך שאני אוהב כל כך דפדפנים ואת ה־web בכלל. בזכות ההתפתחות המהירה שלהם, ב־2026 אותו סיפור יכול לפעול בדפדפן, בארכיון עצמאי וביישומים ל־Windows ול־macOS, בלי לבנות כמה מנועי משחק נפרדים.

לפני השקת הייבוא והייצוא באוגוסט 2026 הייתה ב־Romergo במשך זמן רב בעיית vendor lock-in: המשתמש יכול היה ליצור בתוך המערכת, אבל התקשה לקחת איתו את העבודה המלאה. היום זה כבר לא המצב. בעל הפרויקט יכול להוריד ארכיון .romergo מתועד או להכין משחק עצמאי ל־web, ל־Windows, ל־macOS ול־Microsoft Store. הפרויקט צריך להישאר בבעלות המחבר גם אם יום אחד יחליט לעזוב את Romergo.

לכן התחלתי לעבוד על ייבוא וייצוא.

איך ה־web הקטין מאוד את המשימה

ל־Romergo כבר היה Player runtime משותף שמריץ סצנות, הסתעפויות, תמונות, מוזיקה, וידאו, תרגומים, שפות RTL ושמירות מקומיות. בדרך כלל הוא טוען סיפור שפורסם מהשירות, אבל אפשר לארוז אותו יחד עם הסיפור ולנתק לחלוטין את הרשת.

גרסת ה־Web שמה index.html בשורש קובץ ה־ZIP. גרסאות Windows ו־macOS עוטפות את אותו Player במעטפת Electron מוקשחת. Microsoft Store מקבלת את אותו משחק בתוך MSIXUpload. לא כותבים מחדש את לוגיקת הסיפור ארבע פעמים; רק האריזה מסביב ל־runtime אחד משתנה.

חתימות, אישורים, notarization, כללי חנויות וחשבונות מפתחים עדיין נדרשים. אבל החלק היקר ביותר כבר אינו מוכפל: לקוח נפרד והתנהגות שונה בכל פלטפורמה.

איך הייצוא עובד

Romergo לא מעתיקה מצב מקרי או חלקי מהעורך. היא לוקחת טיוטה במצב Saved או גרסה שמורה מסוימת של פרסום. גרסאות ה־runtime והנכסים ננעלות ל־revisions מוגדרים. אם הפרויקט משתנה בזמן הבנייה, המשימה מופעלת מחדש במקום לערבב סצנות ישנות עם קבצים חדשים.

התוצאה הראשונה היא תמיד .romergo: קובץ ZIP רגיל בעל מבנה מתועד. הוא כולל manifest, פרויקט, פרקים, סצנות, תרשים זרימה, משתנים, תצוגה, מדיה, credits ו־SHA-256 checksums. הארכיון שומר שמות מוצגים ותפקידי תורמים, אך לא כתובות דוא״ל או מזהים פנימיים.

טיוטה שמורה או פרסום
        ↓
גרסאות עקביות של runtime ונכסים
        ↓
ארכיון .romergo מתועד
        ↓
בונה פלטפורמות מבודד
        ↓
ZIP או MSIXUpload פרטי למשך 7 ימים

כל נכס נקרא ומקבל hash, ונבדק שוב לפני הכתיבה. הארכיון נבנה בהזרמה ונשלח ישירות ל־R2 פרטי, ולכן ה־Worker אינו צריך להחזיק פרויקט של כמה GB בזיכרון.

אם המשתמש צריך רק פרויקט לעריכה, התהליך מסתיים כאן. לבניית משחק, .romergo נשלח לקונטיינר Linux מבודד ללא גישה לאינטרנט. הקונטיינר מאמת את הארכיון, מוסיף Player עצמאי ומפיק אחת מהאפשרויות הבאות:

• Web / itch.io ZIP עם index.html בשורש;
• Windows x64 ZIP עם שמירות מקומיות, תבנית SteamPipe ו־signing kit מקומי;
• macOS ZIP עם יישומים נפרדים ל־Apple Silicon ול־Intel;
• MSIXUpload עם identity שהמשתמש קיבל מ־Microsoft Partner Center.

Romergo אינה מבקשת Steam credentials, ‏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.

AI אינו מחליף בדיקה

הסוכן מבין משמעות, אבל השערה אינה עובדה. אודיו עשוי לדרוש תמלול חיצוני, קישור לסרטון אינו מעניק זכויות שימוש, וקוד Ren’Py מורכב או Twine macro עשויים להיות תוכנה בפני עצמם. לכן תהליך הייבוא מציג preview ו־warnings ומבקש אישור לזכויות על החומרים לפני יצירת הפרויקט.

המייבא המקורי של Romergo מקבל רק .romergo. זו החלטה מכוונת: הפורמט הפתוח שלנו צריך להיקלט באופן דטרמיניסטי ובטוח; את העולם הבלתי מוגבל של מקורות חיצוניים עדיף לפרש באמצעות כלי שיודע להסיק מסקנות ולשאול שאלות.

הימור על חמש השנים הבאות

פורמטים ישתנו, וכך גם מודלים וסוכנים. אבל הגבול יכול להישאר יציב: מצד אחד כל חומר אנושי, ומצד אחר .romergo מתועד וכלי היצירה של MCP.

אם יופיע בעתיד עורך פופולרי חדש, Romergo לא תצטרך להמתין ל־importer מיוחד. הסוכן יוכל ללמוד את הקבצים, להראות מה הבין ולכתוב את התוצאה דרך אותו חוזה. ואם המחבר יעזוב את Romergo, עדיין יישארו בידיו ארכיון פתוח ומשחק עצמאי.

מבחינתי זה הכיוון הנכון: Romergo צריכה להיות מקום נוח ליצור בו סיפורים, לא כלוב שאי אפשר להוציא אותם ממנו.

חזרה לבלוג הפיתוח