Hehehe, well for us, it isn't 2 lines of code. Maybe when you call it . But other than that, it is several lines of code which are easily managed if you have a good design up front. I think that is simplifying the process a bit too much? I'll admit I'm not an Obj-C guy, so we don't use CPreferences. So for all I know, maybe it is a super-duper all knowing context saver. We do pretty much everything in C++. Our save data system uses our own serialized data structures we wrote. This stuff runs on PC, Mac, iPhone. We were a dev for some of first iPod games ... and it worked for that too. So the system is highly portable. If you build from the start in your classes a method that "knows" how to serialize it's data (as well as can be inherited), it is easy. There is no free lunch, so it requires some discipline. We typically have a section in our class structures that we define our variables that need to be saved/restored. It is separated to make us think about what we put there. We use that to then force us to ensure we update our serializer. Yes, it requires discipline. But it works well, and you will be rewarded later. Our system has supported games where we had 100+ entities of different types and animation/physics state being restored properly. There are other ways as well, of course. Some which will be more elegant as well. But that is the generalized basis of what you need. There are a few more tricks you need, because you need to still establish a relationship between data and objects on both the save and more importantly the recovery.
i dont do C++, i do pure C the great thing with that decision is that your data is separated from your code. i still program in an object orientated manner but yes, when you uses C++ and classes; you need to do it for every single object and it becomes a mess. this is why i mention it from a design point of view.. if you had a single structure; that you could serialize in one write/read statement; and your objects referenced values inside that structure via pointers - you could do it in C++ as well. which is more work? defining a simpler structure? or having to serialize a bunch of objects and deal with the issues.. i've been a developer for 20+ years, hence i've found a solution that works well for me i also am not an objective-C guru; but i use this solution. on other platforms; i typically just write the structure to a file.. which is also a few lines of code.
Heh. I also do C as well. And I'll even confess, much to my horror, that I've been using more of Obj-C in some cases since we've been slowly using more UIKit ontop of our OpenGl and I've been getting more exposure to that language. There are many ways to skin the cat. C does give you the luxury of being able to dump out your data structure pure. Which is really the easy way of doing it! We cheat that way in many cases as well . But of course, there are some issues. Like, for example, you wanted to portable file format but you used enums as data elements. The size of those particular data elements are dependent on the compiler settings. This problem still exists with a C++ serializer too, BTW, if you don't do it right. The biggest item, however, that is problematic in a game setting is pointers. In this case, writing your struct to file will not work, since there is no "pointer reference" to return to on the restore. But I'm assuming you probably have a work around for that ... since it most certainly isn't a difficult problem to solve !
C just overtook Java as the "best" languages (subjective, but i thought i would mention it) i prefer to use constants over enumerations for that purpose. another issue is endianess; but, that isn't that difficult to deal with. yes. i actually have a game state structure; inside it are a bunch of pointers which are loaded on initialization and free'd on termination (back to OO principles) - they are static and differ between executions. when working with "in application" pointers; you can save the contents and any references within can be relative.. i try to avoid those circumstances if i can however. but as you say; many ways to skin a cat. i just wanted to point out that it can be easy to add if you put a little thought into the design. there is no excuse why developers do not provide save state - it comes down to experience and laziness.
