გადატანადობა

იმპორტი და ექსპორტი: ისტორია თქვენი უნდა დარჩეს

ეს კიდევ ერთი ამბავია იმის შესახებ, რატომ მიყვარს ასე ძალიან ბრაუზერები და web. მათი სწრაფი განვითარების წყალობით, 2026 წელს ერთი და იგივე ისტორია შეიძლება გაეშვას ბრაუზერში, ავტონომიურ არქივში, Windows-ისა და macOS-ის აპებში რამდენიმე დამოუკიდებელი სათამაშო ძრავის შექმნის გარეშე.

2026 წლის აგვისტოში იმპორტისა და ექსპორტის გაშვებამდე Romergo-ში დიდი ხნის განმავლობაში არსებობდა vendor lock-in-ის პრობლემა: მომხმარებელს შეეძლო სისტემაში შეექმნა ნამუშევარი, მაგრამ მისი სრულად წაღება რთული იყო. ახლა ეს ასე აღარ არის. პროექტის მფლობელს შეუძლია ჩამოტვირთოს დოკუმენტირებული .romergo არქივი ან მოამზადოს ავტონომიური თამაში web-ისთვის, Windows-ისთვის, macOS-ისთვის და Microsoft Store-ისთვის. პროექტი ავტორს უნდა ეკუთვნოდეს მაშინაც კი, თუ ის ოდესმე Romergo-ს დატოვებს.

ამიტომ დავიწყე იმპორტსა და ექსპორტზე მუშაობა.

როგორ შეამცირა web-მა ეს ამოცანა

Romergo-ს უკვე ჰქონდა საერთო Player runtime, რომელსაც შეუძლია სცენების, განშტოებების, სურათების, მუსიკის, ვიდეოს, თარგმანების, RTL ენებისა და ლოკალური შენახვების მართვა. ჩვეულებრივ, ის გამოქვეყნებულ ისტორიას სერვისიდან ტვირთავს, თუმცა შესაძლებელია მისი ისტორიასთან ერთად შეფუთვა და ქსელის სრულად გამორთვაც.

Web build ZIP-ის ფესვში ათავსებს index.html-ს. Windows და macOS იმავე Player-ს დაცულ Electron shell-ში ფუთავენ. Microsoft Store კი იმავე თამაშს MSIXUpload-ის სახით იღებს. ისტორიის ლოგიკა ოთხჯერ არ იწერება, იცვლება მხოლოდ შეფუთვა ერთი runtime-ის გარშემო.

ხელმოწერები, სერტიფიკატები, notarization, მაღაზიების წესები და developer account-ები მაინც საჭიროა. მაგრამ ყველაზე ძვირადღირებული ნაწილი აღარ მეორდება: ცალკე client და განსხვავებული ქცევა თითოეული პლატფორმისთვის.

როგორ მუშაობს ექსპორტი

Romergo არ აკოპირებს editor-ის შემთხვევით ან დაუსრულებელ მდგომარეობას. ის იღებს Saved სტატუსის მქონე draft-ს ან publication-ის კონკრეტულ შენახულ ვერსიას. Runtime და assets კონკრეტულ revision-ებზე ფიქსირდება. თუ build-ის დროს პროექტი შეიცვალა, job თავიდან სრულდება და ძველი სცენები ახალ ფაილებს არ ერევა.

პირველი შედეგი ყოველთვის .romergo-ა: ჩვეულებრივი ZIP დოკუმენტირებული სტრუქტურით. მასში შედის manifest, project, chapters, scenes, flow graph, variables, presentation, media, credits და SHA-256 checksums. არქივი ინახავს contributors-ის საჩვენებელ სახელებსა და როლებს, მაგრამ არა email-ს ან შიდა ID-ებს.

შენახული draft ან publication
        ↓
თანმიმდევრული runtime და asset revisions
        ↓
დოკუმენტირებული .romergo არქივი
        ↓
იზოლირებული platform builder
        ↓
private ZIP ან MSIXUpload 7 დღით

თითოეული asset იკითხება, იჰეშება და ჩაწერამდე კიდევ ერთხელ მოწმდება. არქივი streaming-ით პირდაპირ private R2-ში იწერება, ამიტომ Worker-ს მრავალგიგაბაიტიანი პროექტის memory-ში შენახვა არ სჭირდება.

თუ მომხმარებელს მხოლოდ რედაქტირებადი პროექტი უნდა, პროცესი აქ სრულდება. თამაშის build-ისთვის .romergo ინტერნეტის წვდომის არმქონე იზოლირებულ Linux container-ში გადადის. Container ამოწმებს არქივს, ამატებს offline Player-ს და ქმნის ერთ-ერთ შედეგს:

• Web / itch.io ZIP, რომლის ფესვშიც index.html დევს;
• Windows x64 ZIP ლოკალური შენახვებით, SteamPipe template-ითა და local signing kit-ით;
• macOS ZIP ცალკე აპებით Apple Silicon-ისა და Intel-ისთვის;
• MSIXUpload იმ identity-ით, რომელიც მომხმარებელმა Microsoft Partner Center-იდან მიიღო.

Romergo არ ითხოვს Steam credentials-ს, Apple Developer ID-ს, სერტიფიკატებს ან პაროლებს. ხელმოწერა და გამოქვეყნება ავტორის საკუთარ ანგარიშებში რჩება. სერვისი ამზადებს ატვირთვისთვის გამზადებულ build-ს, შვიდი დღე private-ად ინახავს და owner-ს მოკლევადიან download link-ს აძლევს.

ფასმაც გამაკვირვა. Production-ზე არსებული “Blizzard” შეიცავს დაახლოებით 30 MB მოცულობის 101 media file-ს. Cloudflare-ის გეგმაში ჩართული რესურსების ამოწურვის შემდეგაც კი, მიმდინარე ტარიფებით ერთი platform export მხოლოდ რამდენიმე cent ღირს. ძირითადი ხარჯი R2 ან traffic კი არა, შეფუთვის დასრულების შემდეგ container-ის სიცოცხლის დრო აღმოჩნდა.

შეგიძლიათ browser-ში ითამაშოთ “Blizzard”-ის production ვერსია. ეს იგივე პროექტია, რომელიც ღირებულების დასათვლელად გამოვიყენეთ.

იმპორტი უფრო რთული იყო

ვიზუალური ნოველების editor-ებისა და engine-ების რაოდენობა უკვე ათზე მეტია. ზოგი ავტორი Twine-დან, ink-იდან, Yarn Spinner-იდან ან Ren’Py-დან მოდის; სხვები Notepad-ში, Obsidian-ში ან Notion-ში წერენ. მასალა შეიძლება იყოს PDF, Markdown, ცხრილები, ხმოვანი ჩანაწერები, ვიდეოს ბმულები და სურათების საქაღალდეები.

ფორმატი ათასობითაა და ყოველწლიურად იცვლება. თითოეულისთვის native importer-ის დაწერა ხუთ წელიწადში ძველი third-party ვერსიების მცოდნე parser-ების სასაფლაოს შექმნიდა.

პასუხი უკვე ხელთ მქონდა: AI agents.

Agent-ს შეიძლება გადავცეთ HTML, Markdown, PDF, audio, images და links. მას შეუძლია აღადგინოს თანმიმდევრობა, იპოვოს განმეორებადი პერსონაჟები, მონიშნოს ბუნდოვანი განშტოებები და ავტორს კითხვები დაუსვას. ადამიანი პროცესს მიმართულებას აძლევს და შედეგს ამოწმებს.

Romergo-ს MCP support უკვე ჰქონდა. ამიტომ, მსოფლიოს ყველა ფორმატის Romergo-სთვის სწავლების ნაცვლად, სტაბილური სამიზნე დავტოვე: tools, რომლებითაც agent ჩვეულებრივ Romergo project-ს ქმნის და ამოწმებს.

იმპორტის flow agent-ის გავლით

source files და links
        ↓
მომხმარებლის MCP-compatible agent
        ↓
inventory, preview, questions და warnings
        ↓
Romergo MCP authoring tools
        ↓
persisted readback და project validation
        ↓
ავტორის საბოლოო შემოწმება Builder-ში

ჯერ მომხმარებელი MCP-compatible agent-ს აკავშირებს და source materials-ს გადასცემს. Agent ქმნის chapters, scenes, characters, locations, media, languages და relations-ის inventory-ს. HTML, Markdown, TXT და ტექსტური PDF-ისთვის romergo_inspect_story_source და romergo_import_story_source გამოგონილი განშტოებების გარეშე 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-ად ტვირთავს და graph-სა და scenes-ს წერს. დიდი media one-time upload-ით პირდაპირ R2-ში მიდის. შემდეგ agent romergo_get_chapter-ით შენახულ მონაცემებს ხელახლა კითხულობს, უშვებს romergo_validate_project-ს და migration-ს მხოლოდ romergo_verify_quest_change-ის წარმატების შემდეგ ასრულებს.

AI შემოწმებას არ აუქმებს

Agent-ს მნიშვნელობის გაგება შეუძლია, მაგრამ ვარაუდი ფაქტად არ იქცევა. Audio-ს შეიძლება external transcription დასჭირდეს, ვიდეოს link გამოყენების უფლებას არ იძლევა, ხოლო რთული Ren’Py code ან Twine macro შეიძლება დამოუკიდებელი პროგრამა იყოს. ამიტომ import flow აჩვენებს preview-სა და warnings-ს და project-ის შექმნამდე მასალებზე უფლებების დადასტურებას ითხოვს.

Romergo-ს native uploader მხოლოდ .romergo-ს იღებს. ეს განზრახაა: ჩვენი open format deterministic და უსაფრთხოდ უნდა იმპორტირდეს, გარე წყაროების უსასრულო სამყარო კი უკეთ ესმის tool-ს, რომელსაც მსჯელობა და კითხვების დასმა შეუძლია.

არჩევანი მომდევნო ხუთი წლისთვის

ფორმატები, მოდელები და agents შეიცვლება, მაგრამ საზღვარი შეიძლება სტაბილური დარჩეს: ერთ მხარეს ნებისმიერი ადამიანური მასალა, მეორე მხარეს დოკუმენტირებული .romergo და MCP authoring tools.

თუ მომავალში ახალი პოპულარული editor გამოჩნდება, Romergo-ს ცალკე importer-ის ლოდინი არ დასჭირდება. Agent შეძლებს მისი ფაილების შესწავლას, საკუთარი გაგების ჩვენებას და შედეგის იმავე contract-ით ჩაწერას. ხოლო თუ ავტორი Romergo-ს დატოვებს, მას მაინც დარჩება open archive და autonomous game.

ჩემთვის სწორი მიმართულება სწორედ ესაა: Romergo უნდა იყოს ადგილი, სადაც ისტორიების შექმნა მოსახერხებელია და არა გალია, საიდანაც მათი წაღება შეუძლებელია.

დაბრუნება dev-ბლოგში