Thoughts on the App Store

[Sherry Haibara]

I think you have no more excuses now

The NDA is dropped, and we have already discussed a lot about the non-problem of the execution of interpreted code. Many apps that run interpreted code have been published without a hitch, and some of them are even based on open-source software.
Even the transfer of files is a non-problem, because you can always transfer them with free iPhone apps.
So the only remaining "problem" is the auto-save question, but honestly I think most people can just forget about it. ScummVM on app store would be awesome.

Just my 2 cents,
Sherry Haibara

[maxd]

I haven't investigated but I am pretty sure that the applicationWillTerminate delegate notification will do the whole "save when you press the Home button" stuff.

It would be a bit ridiculous for Apple NOT to let an application clean up after itself when quitting, and very backwards. Having said that, nothing surprises me these days.

Max

[edken]

I have been following this thread for a long time now and I just wanted to reply to the last comment.
First let me say I love scumvm, it rocks. I have been using it on my PC for years, had it on an old S.E. Phone and would love to have it on my iPhone. I'm not going to jail break my phone however under any condition and so would love to be able to get of through the app store. I would be willing to pay a decent price or it as well. But I don't just expect that because it's now simpler maybe for this to happen that people who get no money in return for the hours spent to make scumvm work for the app store should just drop everything to forfil our whims.
Especially as apple may very well not let it through their inexplicable aceptance process.
I personally have sent a few emails to apple asking them to maybe shine some light on the matter. (not that I expect they even read them).
But I was thinking would it be an idea to start a thread on here as a petition to apple asking them to spefically allow this great potential app? Who would be willing to sign?

[fingolfin]

I haven't investigated but I am pretty sure that the applicationWillTerminate delegate notification will do the whole "save when you press the Home button" stuff.

It would be a bit ridiculous for Apple NOT to let an application clean up after itself when quitting, and very backwards. Having said that, nothing surprises me these days.

Max

You are both right and wrong . Of course an app can clean up after itself. That was never the problem.

The problem is implementing "save at any time". Because that's what you'd have to do when you may have to quit (which is effectively what is happening) at any time (when the Home button is pressed, when there's an incoming call, etc.). Apple does not and can not automate that for application developers.

In particular, it is still as complicated as it used to be.

[fingolfin]

I think you have no more excuses now

Really, such "jokes" make me sick. This is not about excuses, this is about legal issues, and about lots and lots of our *spare time* we need to invest.

The NDA is dropped, and we have already discussed a lot about the non-problem of the execution of interpreted code.

Have "we" done that? Last I heard was that some people said "Gee, I broke the rules and nobody sued me", but that doesn't change the facts. Just because Apple does not enact their own rules does not void them, and does not really make it any more appealing to target their platform.


Please consider what you write before you write it.

[Sherry Haibara]

I think you have no more excuses now

Really, such "jokes" make me sick. This is not about excuses, this is about legal issues, and about lots and lots of our *spare time* we need to invest.

The NDA is dropped, and we have already discussed a lot about the non-problem of the execution of interpreted code.

Have "we" done that? Last I heard was that some people said "Gee, I broke the rules and nobody sued me", but that doesn't change the facts. Just because Apple does not enact their own rules does not void them, and does not really make it any more appealing to target their platform.


Please consider what you write before you write it.

About the first thing, I was clearly ironic. But hey, people around here just don't know what sarcasm is.
About the second thing: it seems that the whole problem is about "legal issues", right?
But aren't you just breaking the rules by making ScummVM a jailbroken app?
You are using an unofficial toolchain, which is not Apple-authorized; moreover, you are actually suggesting that people who want to use ScummVM need to break the rules jailbreaking their devices.
Isn't this just an enormous nonsense?
If you have legal questions about the execution of interpreted code, then e-mail Apple engineers and ask 'em, or open a topic in the Apple forums.

Sherry Haibara

[fingolfin]

About the first thing, I was clearly ironic. But hey, people around here just don't know what sarcasm is.

Actually, sarcasm and irony are concepts which highly depend on cultural background, do not carry well through written media, and are heavily influenced by language barriers, too.

I.e. what seems to be "clearly ironic" may seem to be "clearly insulting" to somebody else, and vice versa. Personally, I love and use sarcasm & irony (two very different things, btw) a lot in personal communications, but as a general rule of thumb, I can only recommend against using irony & sarcasm in internet forums, because of the above mentioned problems.

About the second thing: it seems that the whole problem is about "legal issues", right?
But aren't you just breaking the rules by making ScummVM a jailbroken app?
You are using an unofficial toolchain, which is not Apple-authorized; moreover, you are actually suggesting that people who want to use ScummVM need to break the rules jailbreaking their devices.
Isn't this just an enormous nonsense?
If you have legal questions about the execution of interpreted code, then e-mail Apple engineers and ask 'em, or open a topic in the Apple forums.

Sherry Haibara

It's a tad more complicated than that. We explained in previous posts in this thread and elsewhere what technical issues there are.

As to the legal issues: Apple can not prohibit anybody from using a compiler tool chain for producing binaries we like, nor can they legally prevent us from distributing binaries, as long as those do not infringe with any of their terms, NDAs, etc.. In particular, we are not violating any agreement we have signed.

However, the moment we want to distribute stuff through the app store, we have to enter a contract relationship with Apple. Implying that we have to agree to be bound by the terms of the app store and to uphold all requirements imposed by it. Legally, ScummVM (and Frotz, and other apps) are incompatible with those terms, hence it is impossible for us (and them) to actually uphold them. If Apple lets it slip by, unofficially saying it's OK, then that's sad -- because then, why do they not just change their stupid terms to something sane?

[maxd]

The problem is implementing "save at any time". Because that's what you'd have to do when you may have to quit (which is effectively what is happening) at any time (when the Home button is pressed, when there's an incoming call, etc.).

I am interested, from an engineering point of view, what the difference is. Surely there is no need to "save at any time" because the applicationWillTerminate delegate notification is called at any time ScummVM is going to be exited and unloaded from memory, by the user pressing the Home button?

I am new to iPhone dev so I'm not clear on the intricacies; if you have investigated applicationWillTerminate already I'd love to know your findings about why it's not applicable. I'm a software engineer at a leading independent game developer, so I can handle technical words.

Max

[Vinterstum]

I am interested, from an engineering point of view, what the difference is. Surely there is no need to "save at any time" because the applicationWillTerminate delegate notification is called at any time ScummVM is going to be exited and unloaded from memory, by the user pressing the Home button?

I am new to iPhone dev so I'm not clear on the intricacies; if you have investigated applicationWillTerminate already I'd love to know your findings about why it's not applicable. I'm a software engineer at a leading independent game developer, so I can handle technical words.

Max

Basically, ScummVM (specifically, some/most of its engines) is not built to be able to save its state at any given time.

For an emulator, this would be easy. However, since ScummVM is actual engine reimplementations (pure native code), we're left with normal game saves, pretty much (manually writing specific data to disk). And since this would be triggered at any time, the engines would need to be in a saveable state at any time (any time they call into the backend, at least). Which isn't the case. Meaning you'd end up with broken savegames quite often (I remember we had problems with this in Kyra for example, when we added a hotkey for quicksaves. This key worked during dialogs (IIRC), a situation where the normal save menu was unavailable, which produced some pretty useless savegames).

Edit: This is solveable, of course. What's unclear is how much work this would be to handle for each engine (that's a question for the engine maintainers).

The jailbroken version bypasses the whole issue by just refusing to exit and instead goes to sleep (checking every 100 ms for wake-up events), but this is banned by Apple for AppStore apps (for reasons I understand but not completely agree with ).

[DrMcCoy]

Edit: This is solveable, of course. What's unclear is how much work this would be to handle for each engine (that's a question for the engine maintainers).

For the Gob engine for example, this is completely out of the question.
The saving and loading is handled by the game scripts, the engine has no control over that at all.

A theoretically solution would entail implementing a complete emulated memory rendering the engine slower by several orders of magnitude (perhaps even too demanding for the iPhone )

[maxd]

For an emulator, this would be easy. However, since ScummVM is actual engine reimplementations (pure native code), we're left with normal game saves, pretty much (manually writing specific data to disk). And since this would be triggered at any time, the engines would need to be in a saveable state at any time (any time they call into the backend, at least). Which isn't the case. Meaning you'd end up with broken savegames quite often (I remember we had problems with this in Kyra for example, when we added a hotkey for quicksaves. This key worked during dialogs (IIRC), a situation where the normal save menu was unavailable, which produced some pretty useless savegames).

Edit: This is solveable, of course. What's unclear is how much work this would be to handle for each engine (that's a question for the engine maintainers).

That's awesome, thanks for the explanation, it makes complete sense now. The game engine I work on is entirely deterministic so we can save out the game state at any time and it will quite happily load up again; I guess I just take that for granted these days.

Would a potential solution be to provide callbacks for each engine to say "shit, we need to save now", which would perform whatever actions are required to get the game into a savable state and then perform the save. I don't have ScummVM to hand right now, but surely in most games you can just hit escape and the click the save button?

Cheers,

Max

[DrMcCoy]

Would a potential solution be to provide callbacks for each engine to say "shit, we need to save now", which would perform whatever actions are required to get the game into a savable state and then perform the save. I don't have ScummVM to hand right now, but surely in most games you can just hit escape and the click the save button?

Again, an example where this isn't possible is the Gob engine.
Strictly speaking, the engine doesn't even know what saves are (it only gets to see "write n bytes from the variables array at offset m to file o at offset p"). Let alone what a savable state is.

[nferno]

I've got a slightly different take on the "ScummVM should auto-save on exit" problem. I'd solve the problem like this:

Whenever ScummVM knows it's about to enter a state in which you can't change the game, ScummVM should save the game, just before it enters such a state. (This does assume ScummVM knows when it can and cannot save a game...)

Whenever ScummVM should shut itself down and it knows it can save the game, then it should do so (obviously ). If it can't save the game at that time, it should simply use that auto-save that was created just before the non-saveable state was entered.

With this solution, you'll at least have a game that was saved at the very last time it was possible to save the game. I think this is an acceptable solution, as most of your playing time is spent in places where it's possible to save the game.

A simpler alternative solution, but still an acceptable one: If you want to quit the game and use the quit-button from the main menu, you should get a yes/no-dialog "Do you want to save the game before exiting ScummVM?". If it's impossible to save the game at that time, you should get another dialog: "Any unsaved progress will be lost. Are you sure you want to quit ScummVM?" Of course, this solution is a bit confusing if you don't know why it sometimes gives the first dialog and sometimes the second one...

[fingolfin]

In general, the idea is not bad, only...

(This does assume ScummVM knows when it can and cannot save a game...)

sadly, you assume incorrectly. :/

That said, for *some* games/engines this might be possible, just like *some* games/engines might be able to save at any place. But in general, this is not the case. Some more engines/games might be enhanced to support one or both of these (by hard work, mind you; this is not an easy take, just not impossible). For some engines/games, though, it will be out of question forever, simply because these things are controlled by game scripts.

A simpler alternative solution, but still an acceptable one: If you want to quit the game and use the quit-button from the main menu, you should get a yes/no-dialog "Do you want to save the game before exiting ScummVM?". If it's impossible to save the game at that time, you should get another dialog: "Any unsaved progress will be lost. Are you sure you want to quit ScummVM?" Of course, this solution is a bit confusing if you don't know why it sometimes gives the first dialog and sometimes the second one...

You wouldn't want such a dialog to pop up when your phone is ringing though, would you?

[nferno]

Hmm I see... Would it be acceptable if my solution ("save right before you enter an unsaveable state") were only implemented for the engines where ScummVM knows when it can save and when it can't?
In the meantime, ScummVM could display a subtle warning message whenever you start/restore a game that uses the pesky engines, something like "Autosave is currently unsupported for this game!".

Edit: Or... you could make it sound more positive and say "This game has autosave support!" for the engines where it does work. :p

Also, I've got one more (pretty quick'n dirty) idea. It does depend on this question: Is ScummVM able to detect whether a savegame is valid or corrupt (without crashing )?

If so, you could make ScummVM attempt to autosave every x minutes to some temporary file. After ScummVM has attempted to save the game, it could try to verify whether the file is a valid savegame or a corrupt one. If it's valid, ScummVM may keep this savegame and throw away the previous valid autosave. If it's corrupt, throw it away and hang on to the last valid autosave ScummVM has made.

I know it's an incredibly ugly solution, but it'd still be nice if it worked (even though it'd only serve as a temporary solution).