RE: [Rails-devel] Saving and logging.

[Brett L. <wak...@ea...>]

Hmm...  

I think the big factor here is ensuring that when loading a save file, we=
 don't redraw the whole game.

So long as we're just looping through the game logic without involving the=
 GUI, I think it'll be reasonably fast to load a game.

In additon, what we can do is something like this:

When the user selects "save game" at the end of the play log, we add the=
 status of the game as it currently stands so that when we load the save=
 file, we check the last entry first. If the last entry is the state of the=
 whole game, we load that without forcing a full replay.

---Brett.


*********** REPLY SEPARATOR  ***********

On 3/7/2005 at 10:50 AM Stewart Thain using wsr...@ho... declared:

>For me, the key question about using a replay log as the game save
>mechanism 
>is - will it be fast enough when the replay logs are large late in the
>game?
>
>If there are a large number of "actions" to be replayed to take the game 
>state from "start" up to SR "M" and OR "N" then this may become an
>irritant 
>on a relatively slow computer.
>
>On frequency of writing to disk - if it is to be a secure game recovery 
>mechanism, then IMHO it needs to write to disk, and flush that write to 
>disk, after *every* action - this is basically how most transaction
>oriented 
>database systems work.
>
>It would be annoying to lose most of an SR or OR simply because someone,
>in 
>their excitement, accidently kicked the power cable out!
>
>Stewart
>
>>From: "Brett Lentz" <wak...@ea...>
>>Reply-To: rai...@li...
>>To: rai...@li...
>>Subject: RE: [Rails-devel] Saving and logging.
>>Date: Sun, 06 Mar 2005 13:43:06 -0800
>>
>>
>>
>> >> I've been thinking about the game-save and game requirements,
>> >> and it seems
>> >> to me
>> >> that these are best served by a single solution: All the
>> >> user's funtional
>> >> input,
>> >> e.g. "Fred buys a B&O share", "PRR lays a #9 on H14/ew"
>> >> should be saved in a
>> >> replayable log. This log could be held in memory
>> >
>> >Why not written to a file immediately?
>> >Granted that Windows does not crash that often these days,
>> >but why take the risk?
>>
>>My preference is to have these written to a temp file when we transition 
>>from stock round to operating round and from operating round to stock 
>>round.
>>
>>Then, when the user wants to save the game, we just move the temp file to=
 
>>the user-specified location.
>>
>>I don't think we need to be constantly writing out to the disk, but we
>also 
>>don't want to wait _too_ long before saving the game.
>>
>>
>>---Brett.
>>
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick
>>_______________________________________________
>>Rails-devel mailing list
>>Rai...@li...
>>https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>_______________________________________________
>Rails-devel mailing list
>Rai...@li...
>https://lists.sourceforge.net/lists/listinfo/rails-devel


********** REPLY SEPARATOR END **********
This message sent with 100% recycled electrons.