Any suggestions for a better way to play Twine games on iOS?
A couple times recently while playing Twine games in Safari, I’ve had the unfortunate experience of being fairly far along and then mistakenly navigating away and losing all progress.
Has anyone else run into that? Are there browser settings that can help prevent that? Or some kind of dedicated player app where that can’t happen?
What exactly do you mean by “navigating away”?
The problem with ios and ipad os is, that the local storage in safari is cleared automatically when the tab group becomes inactive. A tab group becoming inactive is completely intransparent for the user. I tested alot with my game Chronicles of the Moorwakker, sadly to no success. In the end I added a save to file functionality for apple users.
One example is triggering a “Back” in the browser.
When you tap a Play Online link from the IFDB, Safari opens it in a new tab and if you go Back it closes that tab.
If a game has a landing page prior to starting the game, Back will take you to that landing page, and you can often undo by going forward. But some games have no landing page (like ones that use the ifarchive “unboxing” service) and Back just immediately closes the tab.
I think there are a variety of other ways a tab can be inadvertently closed or “become inactive” (as @Jupp mentioned), which just makes things feel very fragile when it comes to the game state.
What you describe is a common problem with single-page web-applications, because navigation between the different “screens” within the application are not done using the web-browser’s own web-page navigation system.
eg. no web-page navigation is actually occurring within the application, so the web-browser’s web-page navigation history system is not being updated.
And while it is technically possible for a single-page web-application to programmatically fake web-page navigation so the web-browser’s history is updated, that can lead to other issues due to the potentially very large number of fake “records” that need to be added to that history.
eg. potentially one fake “record” for every link selection in a Twine based project.
This is one of the reasons why the main Twine Story Formats handle their own Undo/Redo, instead of relying on the web-browser’s own equivalent.
Dumb question:
Does Twine not have a save game?
Seems like it’s up to the author. Some do, some don’t.
When an Author creates their Twine project they select which Story Format they want to build with. Each Story Format is a runtime-engine template, that is combined with a project’s Passage data to create a Story HTML file.
The Story Format’s developer decides: what features their engine has; if it includes a macro language the Author can use to code with; what the default User Interface looks like; etc…
Ah, thanks. I thought it would be a core feature. Something to consider when choosing a format.
The “Save” related designs of three of the four main Story Formats:
Harlowe - includes three macros for working with saves: (save-game:); (saved-games:); and (load-game:). The story format’s default User Interface (UI) does not include any “Save” related visual component, the Author is expected to create one if they want such. Saves are stored in the web-browser’s localStorage area.
Chapbook - does auto-saving during the Passage Transition process and automatically resumes where the end-user left of, there is no documented means for an Author to create or load a Save. While the default UI doesn’t include a Save related component, the Author can use the Stage area of the story format’s debugging/testing interface to create & load snapshots. Auto-saves are stored in the web-browser’s localStorage area.
SugarCube - includes a Save API an Author can use to programmatically create & load different types of saves, and a number of Saves Settings that can be use to configure the save system. The default UI includes a Saves dialog that can be used by the Reader to create & load the different types of saves that the story format supports. Auto-saves and Slot based saves are stored in the web-browser’s localStorage area, File based saves are stored external (1) to the web-browser’s own internal storage.
(1) whether or not File based saves are available depends on many things, like: the Web-browser the Reader is using; the Operating System (OS) its being run on; and the Computer or Device that OS is being run on. Where the File is saved to can also depend on the same three things.
I’ve done some experimenting with Twine games in browsers other than Safari on iOS (Firefox, Chrome, and Brave). They’re all better in regard to the issue I mentioned with going Back causing a tab/window to close. They either don’t do that or if they do they provide an undo. So you won’t lose a game in progress due to an accidental swipe…
Regarding saved games, saves to local storage can disappear without warning on iOS (regardless of browser). For example, if your device restarts for an OS update, your local storage saves are gone. That makes file based saves a much better option, but unfortunately, that’s not consistently available in Twine games.
I wonder if a browser extension could be used to save/load local storage for specific sites?
Apple requires all third-party web-browsers that run on iOS to internally use WebKit as their browser engine (1), which can result in those other web-browsers behaving differently than they would when run on other operating systems.
(1) there are some exceptions to this rule, like if the end-user is part of the EU.
Use Hiev’ Local Storage Manager.