★ TouchArcade needs your help. Click here to support us on Patreon.

Multitasking, a question for developers

04-09-2010, 08:58 AM
#1
Senior Member [Original Poster]
Joined: Jul 2009
Posts: 699
Multitasking, a question for developers

Currently the biggest problem, with the lack of multitasking, is the fact that not all developers add the resume functionality. Which means that the game (or app in general) remembers the last state you were in before you quit the game, and let's you continue at the point where you left off.
Now I don't know much about coding, but I'm geussing this is possible for most, if not, all, games.

The 4.0 features multitasking. It has several optional background processes though. The one which will be most important for games is the "fast app switching".
Now my questions are:
1. How is this different from the current situation?
2. Does every app support this, or does it have to be manually coded in?

Because atm some devs don't (because of lack of time, lack of knowledge of this possibility, or w/e) use the resume functionality, why would they use it in 4.0? I'd love multitasking for those games which lack this functionality (THPS2 is a recent example), but from what I can tell 4.0 won't help?
04-09-2010, 09:23 AM
#2
I haven't had the time to look over the sdk yet, so I might be wrong, but from what I understand this will require code to work. In cases where a game is put into the background, it's really a pause/save and load/resume model, not actual multitasking (where the app is still actually running). This makes sense in the context of the hardware/user experience, but likely adds significant work on the code side.

I used <NSCoding> to completely serialize the state of my dual stick shooter out when you save a game in progress or quit. I likely could have shipped without this, but I felt it was a nice feature to have since you might get a call in the middle of playing. That said, even with Apple's nice serialization classes, it's still a lot of work, and many games don't handle this correctly right now.

04-09-2010, 10:14 AM
#3
Senior Member [Original Poster]
Joined: Jul 2009
Posts: 699
Quote:
Originally Posted by slipster216 View Post
I haven't had the time to look over the sdk yet, so I might be wrong, but from what I understand this will require code to work. In cases where a game is put into the background, it's really a pause/save and load/resume model, not actual multitasking (where the app is still actually running). This makes sense in the context of the hardware/user experience, but likely adds significant work on the code side.

I used <NSCoding> to completely serialize the state of my dual stick shooter out when you save a game in progress or quit. I likely could have shipped without this, but I felt it was a nice feature to have since you might get a call in the middle of playing. That said, even with Apple's nice serialization classes, it's still a lot of work, and many games don't handle this correctly right now.
So, aside from the obvious apps (streaming, skype, etc) there won't be a difference for us gamers, apart from the fact we get to switch using double home button tap instead of home button+swiping?
04-09-2010, 10:40 AM
#4
Joined: Jul 2009
Posts: 317
Quote:
Originally Posted by Mag View Post
Because atm some devs don't (because of lack of time, lack of knowledge of this possibility, or w/e) use the resume functionality, why would they use it in 4.0? I'd love multitasking for those games which lack this functionality (THPS2 is a recent example), but from what I can tell 4.0 won't help?
In the current iPhone OS 3.x there is no built in way provided by the OS to pause an app and allow it to resume exactly where it left off, it is up to the developer to program their app to save its own state, so that is why not all games do it. I haven't looked at it yet, but I am assuming in 4.0 resume will now be provided by the OS so you should probably see more developers including it since it should be much easier to integrate.
04-09-2010, 10:45 AM
#5
Joined: Feb 2009
Location: San Jose, CA
Posts: 546
Quote:
Originally Posted by lukeca View Post
In the current iPhone OS 3.x there is no built in way provided by the OS to pause an app and allow it to resume exactly where it left off, it is up to the developer to program their app to save its own state, so that is why not all games do it. I haven't looked at it yet, but I am assuming in 4.0 resume will now be provided by the OS so you should probably see more developers including it since it should be much easier to integrate.
This. Right now, including it is a lot of work, and restoring the state properly is difficult. I'm assuming it will be much easier in OS 4.

I assume OS 4 will provide automatically functionally, similar to if I put my computer into standby or hibernate mode -- it saves the RAM contents and reloads them on restart (or something like that)

Last edited by lazypeon; 04-09-2010 at 10:56 AM.
04-09-2010, 12:01 PM
#6
Joined: Nov 2008
Location: Munich, Germany
Posts: 754
Send a message via Skype™ to mobile1up
Quote:
Originally Posted by Mag View Post
Now my questions are:
1. How is this different from the current situation?
2. Does every app support this, or does it have to be manually coded in?
if apple does it right - it should just lower the priority of the application threads (saving all states, so it can restore when it becomes active). the palm webos works in a similar manner; the apps are still running; but at a very low priority = very rarely.. secondly; the apps should be using an event driven state loop; by default, the core apple frameworks provide this (so, all is good)

it is possible to do this without any changes; however, it would be nice for apple to actually send us a notification when the app is being paused and resumed; so we can actually stop audio threads etc.. this is typically manually coded in. it isn't clear yet (i haven't downloaded SDK) - so i cannot answer these questions directly; i can just give experience on how it is done on other platforms.

// Aaron Ardiri
Mobile 1UP is a proud indie developer - support us!
developer of Caveman / Caveman HD and GW Series
04-09-2010, 12:05 PM
#7
Joined: Nov 2008
Location: Munich, Germany
Posts: 754
Send a message via Skype™ to mobile1up
Quote:
Originally Posted by lazypeon View Post
This. Right now, including it is a lot of work, and restoring the state properly is difficult. I'm assuming it will be much easier in OS 4.
are you a developer? come on man.. this is so easy.

store all your game related into a structure, lets save "GameState" and then simply save and restore this structure when you get the pause/resume events. if you design your app right; and dont use a bunch of globals for your application state; this can be done with two lines of code. if a developer doesn't do it now - they are lazy. we added save state to all our games with two lines of code; you can simply use the UserDictionary object within the apple SDK and save a blob of information when you exit; when you re-enter; read it, check if the game is running and then restore it.

of course; *design* is key here. that comes with experience.

// Aaron Ardiri
Mobile 1UP is a proud indie developer - support us!
developer of Caveman / Caveman HD and GW Series
04-09-2010, 12:37 PM
#8
Quote:
Originally Posted by mobile1up View Post
are you a developer? come on man.. this is so easy.

store all your game related into a structure, lets save "GameState" and then simply save and restore this structure when you get the pause/resume events. if you design your app right; and dont use a bunch of globals for your application state; this can be done with two lines of code. if a developer doesn't do it now - they are lazy. we added save state to all our games with two lines of code; you can simply use the UserDictionary object within the apple SDK and save a blob of information when you exit; when you re-enter; read it, check if the game is running and then restore it.

of course; *design* is key here. that comes with experience.
That's fine for simple games, but for anything reasonably complex it can get quite tedious and simply using a game state object isn't enough. For instance, in a bullet hell game you'll need to save the state of every bullet. Doing that outside of the class structure is, well, error prone. This is why NSCoding exists, so you can implement loading/saving for all of your classes easily. However, it gets further complicated when you want to save the state of things that are not class based or not within your coding domain. For instance, the physics representation of a box2d object in motion, or a particle system's current state, or a FBO that's dynamically generated. I've actually serialized out all of these things in the past, and it's hardly 2 lines of code.

I'm personally hoping that all of this is handled without developers having to serialize out the entire game state, ala hibernate on other OS's. For some types of games, manual serialization can add a ton of work for little gain.
04-09-2010, 12:46 PM
#9
Senior Member [Original Poster]
Joined: Jul 2009
Posts: 699
Quote:
Originally Posted by lazypeon View Post
I assume OS 4 will provide automatically functionally, similar to if I put my computer into standby or hibernate mode -- it saves the RAM contents and reloads them on restart (or something like that)
No:

Quote:
Originally Posted by slipster216 View Post
from what I understand this will require code to work
So in both cases it requires additional coding from the developer. I'm worried that if a developer wasnt motivated to do it in the first place, why would that change with 4.0?
04-09-2010, 01:34 PM
#10
Joined: Jul 2009
Location: Zgrunturos and San Francisco
Posts: 595
Quote:
Originally Posted by slipster216 View Post
That's fine for simple games, but for anything reasonably complex it can get quite tedious and simply using a game state object isn't enough. For instance, in a bullet hell game you'll need to save the state of every bullet. Doing that outside of the class structure is, well, error prone. This is why NSCoding exists, so you can implement loading/saving for all of your classes easily. However, it gets further complicated when you want to save the state of things that are not class based or not within your coding domain. For instance, the physics representation of a box2d object in motion, or a particle system's current state, or a FBO that's dynamically generated. I've actually serialized out all of these things in the past, and it's hardly 2 lines of code.

I'm personally hoping that all of this is handled without developers having to serialize out the entire game state, ala hibernate on other OS's. For some types of games, manual serialization can add a ton of work for little gain.
There is really no silver bullet for save game states. It will always be some work, but if you do it properly from the start, it is pretty manageable ... provided you have the discipline to maintain it (eg. when you add or modify objects). One of the problems people in the iPhone dev space have issues is they try to do everything in NSUserDefaults or other low hanging fruit solutions instead of coming up with a robust solution from the get go.

And having multi-tasking and relying on your app to "always be running" as a save game state is not a great strategy. What happens if their phone runs out of battery? And also, if people find the games get laggy because they have way too many apps running ... then what?

My guess on the support you need for the app is an entry point the OS gives you to feed in time ticks. Complexity of folding it into your code will really be determined on how you have built your app.

Go to where the basketball court and arcade go 1 on 1 with Hoops Madness!