In further reasoning of Miriam's theory...
I would assume that you store the persistent state in a database of some
type on the server...
Based on this assumption (which may or may not be the case) I would think
that there could be a triggering mechanism such that a client could "pull"
relevant information for all sectors that they are "near" (ie, could reach
in x number of "moves"). My area of interest happens to be relational
databases, but you could do this easily in a Java server as well.
Say for instance that each "sector" stores itself in a row of a database,
with the sector number as the primary or relational key. There are triggers
on each row such that when the client requests that row, it receives that
row first, and then rows 2-18 are "pushed" while the client explores area 1.
That way, no matter where they go next, the info will already be there.
Likewise the client could then throw it away after 4 or so turns of non-use
since they could not get back to that sector without going back through a
sector which would trigger it to re-load...
Now this is really all dependent on HOW MUCH information we are talking
about. Are we talking about a scene that downloads static and then updates
to the persistent values based on a few numbers, or is each sector created
on the fly from persistent information ? I guess I need a little more info
to try and suggest possibilities.
Very interesting problem though, and good luck. For those of you following
what I'm doing I think there will be a Clue Game 1.1 close to the end of
this week / beginning of next.
Andy
Graduate Assistant
Rochester Institute of Technology
Department of Information Technology
http://www.rit.edu/~amp5315/
