Yes, well it is fairly complex... but it looks like core data is
not a good fit since a basic requirement is that I need it to store
nested arrays of immutable objects and keep the order (I also need
to allow those objects to be inserted at multiple points in the
array). The immutability and the possibility of multiple entries
make an order property unworkable.
Possibly, but you might be pleasantly surprised (not a knowing
hint, just an honest possibility :-)). If you can, try to explain
your needs. Someone might just have a good suggestion (or solid
reasons why not).
The project is a game engine which has 2 graphs. The first is a tree
of events that represent the story. Each "event" in the story is an
immutable object, and there is a special event which represents a
series of events to run in order and one which represents branches
that the player has to choose from. All of these are immutable, and
the main goal is to avoid loading the whole graph which will consist
of 10k-50k events. This graph will be the same for every player.
The second graph represents in-game objects (characters, locations,
items, etc...) and stores any state for the story. These should be
saved off to a separate file, and will be different for each player/
saved game. I also use proxies as context switches to objects in this
graph. A concrete example is the current location, which is a proxy
that pretends to be a location, and forwards all the messages it
receives to the location object where the player is currently
located. This allows events which reference locations/players/etc
that change depending on state to remain immutable.
The event graph is traversed from a background thread which basically
runs through events in order until it needs a user response. I have a
controller set up which communicates with the main thread, and the
background thread blocks until the controller gets a valid response,
at which point it starts unwinding again until it needs another
response or reaches the end. There is no run loop for this thread.
All of this works fantastically for the game, but now I have reached
the point where I can no longer put off save & load. When I started
the project Core Data was not yet available on the iPhone, so the
design did not take it into account. I was thinking that core data
might be able to help me save & load these graphs, but now I am not so
sure. My new plan is as follows:
Create a manager singleton for events which returns an event object
for a given id, and then modify the special events mentioned above to
hold an event's id instead of actual event objects, and then call off
to the manager with the id whenever they need to run an event. Inside
the manager I would either call off to a small sql database with blobs
holding freeze-dried (keyedArchiving) objects & an id column, or save
each event as a file with the id in the filename. I would also have a
cache in the manager to avoid reallocating objects unnecessarily. I
would prefer to have something like core data do this lazy loading for
me, but it may not work in this case.
For the objects that store state, I will just archive them into a save
file.
Thoughts? Does this sound like a reasonable approach, or will core
data actually work for me?
Thanks,
Jon
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
