A fast, easy to use, free, and community supported 2D game engine
lummis
Member
I know I could do
exit(0);and rely on the user to relaunch by tapping the game's icon. But I'd prefer to restart programatically. I want this because I'm providing a way to reset the game (erase high scores, lock levels higher than one, and reset all options to default values). I can make those things happen on the next launch but I don't know how to make the game launch itself.
JonKean
Member
It's much simpler than you'd think. Use no per session data (such as static objects or data), and if you decide you want to completely restart, just call some root delegate class to release and re-instantiate (just the same way the app started up).
but yes, it really sucks relying on something like that and you should avoid needing it in the first place.
lummis
Member
I need to restart because all the resetting happens in the initialize method of the app delegate. That method reads the defaults file and sets a bunch of settings that need to be set differently if it's the first time through. When the user runs the game for the first time he/she gets a 'welcome' screen with some simple instructions and a few other things like that that I don't see how to easily do without re-launching the app.
You could make a separate "LoadSettings" class, import it into the header of the app delegate class, and then just call it's init method from the app delegate. That would give you access to those elements later. You could also set a flag in user defaults to check for the first run. IE. If the value is nil then it's the first run, after the first run, set it to some value.
lummis
Member
Thanks to all for these responses. I think I'll go with hm50's approach. I already have a multi-valued variable that tells the 'initialize' method why the game terminated the last time it ran. I'll define another value for it that means re-initialize. And after thinking about it I see that I can probably refactor some things and call one of the app delegate methods to make it act like it's starting from scratch, as per JonKean's comment.
hm50: I'm curious why you say I might not "get away with exit(0)"?
hm50: I'm curious why you say I might not "get away with exit(0)"?
Apple expects you to allow the user to terminate the app on their own using the home button and removing it from backgrounding if you have that enabled. Using exit(0) goes against that model, and they can reject an app based on "user experience."
I had an app that needed to use exit(0) because the app was spec'd to have a quit button. Apple allowed it because the user was still controlling the termination. That's about the only context I think they'd approve it, but that's probably what you're doing anyway. I haven't tried it lately, but I think they'd approve it for that case.
You must log in to post.
