Your Tour Goes With You: Portable Saves on the Web

A 366-day campaign cannot be treated like a ten-minute browser session.
The player may begin on a desktop, continue from a laptop and later open the same tour on a tablet. A browser may clear storage. A device may be replaced. The soldier's journal, relationships, kit and decisions should not be trapped inside the first machine that happened to load the game.
The web version now has authenticated cloud saves designed to make the tour portable from device to device. Local saving remains part of the system, so a temporary network problem does not have to stop play. When the account and cloud path are available, the current tour can follow the player.
For a game this long, that is not a convenience feature. It is part of the basic promise.
What a portable tour has to remember
The day number is only the beginning.
A meaningful save includes the soldier and current shift, carried and stored kit, ammunition, wear, finances, PX and catalogue orders, care packages, letters, correspondents, relationships, squad state, decisions, journal entries, photographs, historical records, awards, stress, morale and the checkpoints that prevent a resumed day from repeating completed work.
Those systems develop over hundreds of days. Losing one may not crash the game, but it can still break the story. A gift arriving twice, an order disappearing, a relationship stepping backward or a completed event replaying would make the save technically readable and emotionally false.
The compatibility work therefore uses both fresh-tour and long-tour examples. A tested Day 111 Grenadier save carries a dense mixture of inventory, mail, relationships, decisions and history through save, load, copy and reopen. Older partial save shapes receive current defaults without having their existing player history replaced.
The goal is continuity, not merely successful file parsing.
The newer copy should win for a reason
Cross-device play introduces a problem that local saves do not have: two devices can hold different versions of the same tour.
The cloud system protects against a stale remote copy overwriting strictly newer local progress. A rejected revision stops unsafe cloud writes until the conflict can be reconciled, while local saving continues. Refreshing the list of cloud tours does not silently switch the campaign currently being played. Pulled saves retain the time they were actually played rather than pretending the download time was a gameplay session.
These rules are deliberately cautious. When the system is uncertain, preserving the player's newest known work is more important than making the sync indicator look calm.
There is also a difference between removing a tour and losing one. Removing a cloud-backed tour marks it hidden under the retention policy and clears the local copy. Other devices signed into the same account can receive that hidden identity and remove their stale cached copy as well. A failed or empty network response is never treated as permission to delete anything.
Local play and cloud continuity work together
The browser still keeps local campaign data. That gives the game a nearby copy for ordinary play and lets progress continue when a cloud request fails.
When the connection returns, the cloud path can resume under the revision rules. A visible sync conflict can warn the player without converting a network problem into a lost evening.
Not every preference travels with the soldier. Text size, text speed, content detail, motion, flashing, decision pressure and audio mix remain device settings. That is intentional. The campaign is portable; the presentation can be adjusted for the screen and player using each device.
The distinction is worth remembering when moving from desktop to tablet. The tour may arrive exactly where it was left, while the new device still needs its own comfort settings reviewed.
Evidence and production are separate
The current source and automated tests cover cloud pull, versioned saves, conflict protection, hidden-tour reconciliation and long-save compatibility. The owner has also reported authenticated play across iPad, laptop and desktop, including returns to in-progress shifts and a long-running tour beyond Day 120.
Those are strong implementation and play observations. They are not a blanket claim that every future public deployment, account configuration or database migration is correct. A release build still needs its own authenticated, cross-device verification in the actual environment players will use.
The save-health experience also has room to improve. Some cloud pull failures currently leave local play available without presenting the same visible warning used for a version conflict. A final local-storage failure after quota recovery can also need clearer player-facing notice. Protecting the data comes first; explaining its health clearly is the next part of the promise.
Trust is earned one return at a time
Most players will never study save-concurrency rules. They should not have to.
They will judge the system in simpler moments: sign in, see the expected tour, open it on another device and find the same soldier on the same day with the same life intact. Remove a disposable tour and see it stay removed. Lose a connection and keep playing locally. Return later without wondering which copy won.
That ordinary confidence is difficult to build and easy to lose. It deserves the same attention as art, radio or narrative content because every one of those features depends on the save remembering what the player experienced.
P.A.T.H.: Vietnam asks for a long commitment. Portable cloud saves are how the web version begins to return that commitment: the tour belongs to the player, not to one browser.
