Multitasking, a question for developers

Discussion in 'Public Game Developers Forum' started by Mag, Apr 9, 2010.

  1. Mag

    Mag Well-Known Member

    Jul 9, 2009
    704
    0
    0
    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?
     
  2. slipster216

    slipster216 Active Member

    Dec 3, 2009
    30
    0
    0
    Game Developer
    Boston
    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.
     
  3. Mag

    Mag Well-Known Member

    Jul 9, 2009
    704
    0
    0
    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?
     
  4. lukeca

    lukeca Well-Known Member

    Jul 22, 2009
    317
    0
    0
    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.
     
  5. lazypeon

    lazypeon Well-Known Member
    Patreon Bronze

    #5 lazypeon, Apr 9, 2010
    Last edited: Apr 9, 2010
    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)
     
  6. mobile1up

    mobile1up Well-Known Member

    Nov 6, 2008
    754
    0
    16
    Technical Director
    Munich, Germany
    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.
     
  7. mobile1up

    mobile1up Well-Known Member

    Nov 6, 2008
    754
    0
    16
    Technical Director
    Munich, Germany
    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.
     
  8. slipster216

    slipster216 Active Member

    Dec 3, 2009
    30
    0
    0
    Game Developer
    Boston
    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.
     
  9. Mag

    Mag Well-Known Member

    Jul 9, 2009
    704
    0
    0
    No:

    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?
     
  10. mobileben

    mobileben Well-Known Member

    Jul 17, 2009
    595
    0
    0
    Lumpy's Handler
    Zgrunturos and San Francisco
    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.
     
  11. Mag

    Mag Well-Known Member

    Jul 9, 2009
    704
    0
    0
    So currently in the developers 4.0. What happens if you try to multitask, as no apps support it yet, you will just launch the app as if you launched it from the springboard?
    What happens if you try multitasking between apps which currently already have a resume-state (such as hook champ, meteor blitz, etc), does that work like it used to, or will that launch the app aswell?

    Correct me if I'm wrong, but from what I can tell the only difference in 4.0 for gamers, multitasking wise, will be that from that point on we will have to click the home button twice instead of once.
     
  12. mobile1up

    mobile1up Well-Known Member

    Nov 6, 2008
    754
    0
    16
    Technical Director
    Munich, Germany
    the thing is; as a developer - you shouldn't have to do anything except handle focus gain/lost events. developers are already instructed to do this; specifically handle the following two API's.. i just realized; my apps are already multi-tasking co-operative.

    Code:
    - (void)applicationDidBecomeActive:(UIApplication *)application
    {
        // application now has gained focus
        _SHARKFocusEvent(true);
    }
    
    - (void)applicationWillResignActive:(UIApplication *)application
    {
        // application now has lost focus
        _SHARKFocusEvent(false);
    }
    when you lose focus; you should pause your game.. stop playing your audio etc or run in an alternate mode (less UI intensitivity).. this is all about architecture and design. these two hooks have been available since the beginning; if developers haven't been ignoring them - then they should be good to go with multi-tasking.

    apple should handle everything from a process priority point of view - and make it as transparent to the developer as possible. it isn't really a topic that needs discussing if apple does the job right. if they don't then they just shot themselves in the foot by providing a bad multi-tasking operating system.
     
  13. Mag

    Mag Well-Known Member

    Jul 9, 2009
    704
    0
    0
    Okay, forgive me, my coding skills don't exceed 10 year old HTML.
    Are you saying that the code required for the current resume is the same as the code required for the iphone os 4.0 resume?
     
  14. mobile1up

    mobile1up Well-Known Member

    Nov 6, 2008
    754
    0
    16
    Technical Director
    Munich, Germany
    one would assume this - yes. why would it be any different?
     
  15. Mag

    Mag Well-Known Member

    Jul 9, 2009
    704
    0
    0
    Well, I thought there might be several ways of coding in order to get the same result, but only one specific set of code would work with the os 4.0 fast switching.
     
  16. thewiirocks

    thewiirocks Well-Known Member

    Aug 28, 2009
    618
    0
    0
    Expert Software Engineer
    The mechanism used to background a process today is pretty much the exact multitasking that Apple is after. They probably just enhanced it to swap the entire program to long-term storage. (That way foreground processes won't be negatively impacted.) To reconstitute the program, just restore the memory and make the wake-up call. :)

    Of course, there could be interesting limitations there. I haven't looking into the dev info for OS 4 yet, so there may be some "gotchas" to be aware of. Of course, once I do that I can't say anything. :(
     
  17. Carlos

    Carlos Well-Known Member

    Sep 29, 2009
    755
    0
    0
    Software architect, game dev and book author
    xor eax, eax
    Great! I was hoping they follow this approach (as it's an intuitive, already working pattern).
    Thanks God I'm on the safe side! ;)
     
  18. lazypeon

    lazypeon Well-Known Member
    Patreon Bronze

    Maybe I'm doing it wrong. I usually serialize my objects using NSCoder/NSKeyedArchiver, but there's a lot of manual work involved to make sure I serialize/deserialize all of the data properly. For instance, you have a bunch of state variables, and perhaps a lot of entities in the game (enemies, bullets, whatever). You serialize the 'manager', but also need to serialize all of the entities. That might require position, other variables, animation frame, etc... It's tedious (at least the way I do it) because the serialization/deserialization methods for each entity need to be written by hand. If you use any other time sensitive things like NSTimer, you need to make sure they are also restored properly.

    If you're really doing it in 2 lines, I need to read up a bit more :)
     
  19. slipster216

    slipster216 Active Member

    Dec 3, 2009
    30
    0
    0
    Game Developer
    Boston
    he's only counting the top level save command, not all the NScoder crap you have to write (which can easily be thousands of lines of code)
     
  20. mobile1up

    mobile1up Well-Known Member

    Nov 6, 2008
    754
    0
    16
    Technical Director
    Munich, Germany
    thousands - i don't think so. it is simply a matter of design!

    Code:
            // save the block chunk
            CFPreferencesSetAppValue((CFStringRef)@"prefs", nBlock,
                                     kCFPreferencesCurrentApplication);
    
            // commit the preferences
            CFPreferences*******hronize((kCFPreferencesCurrentApplication);
    
    and to load:

    Code:
        // load the block from preferences
        nBlock = (NSString *)
          CFPreferencesCopyAppValue((CFStringRef)@"prefs",
                                    kCFPreferencesCurrentApplication);
    
    ok - thats THREE lines of code.

    what you need to do to make this work; from a design point of view is actually separate your game data from your game objects/classes - so that they can be loaded and saved in a single call. if you do this; it is very easy. otherwise you have to mess around with every single class being saved.. then it gets really ugly quickly.
     

Share This Page