Menu
▾
▴
rails-devel
|
From: Iain A. <ia...@co...> - 2005-03-06 20:49:43
|
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 until the user decides to save the game. This log could then be passed to the next player in a PBEM game, or just used to reload a saved state after closing the program. Advantages are: - PBEM and local user game saves solved by the same code. - No need to overload implementation code with state save/load code. - Easy debugging: "I did the following (log attached), and the program did the wrong thing." - Easy testing: Once you've debugged the previous case, you can replay the game, and see that the code works properly. Whole test suites and regression tests can be built from this. - If everyone in a PBEM game mails the log after their turn to everyone else, cheating becomes impossible, since if you alter the log, any other player can diff your version against their last one, and see what change you've made. I would, of course, strongly favour using an XML format for saving this data. Iain. |
|
From: Erik V. <eri...@hc...> - 2005-03-06 21:34:25
|
All agreed, except one minor point: > 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? > until the > user decides to > save > the game. This log could then be passed to the next player in > a PBEM game, > or just > used to reload a saved state after closing the program. > > Advantages are: > > - PBEM and local user game saves solved by the same code. > - No need to overload implementation code with state save/load code. > - Easy debugging: "I did the following (log attached), and > the program did > the wrong thing." > - Easy testing: Once you've debugged the previous case, you > can replay the > game, and see > that the code works properly. Whole test suites and > regression tests can > be built from this. > - If everyone in a PBEM game mails the log after their turn > to everyone > else, cheating becomes > impossible, since if you alter the log, any other player > can diff your > version against their > last one, and see what change you've made. > > I would, of course, strongly favour using an XML format for > saving this > data. Like: <action actor_type="company" actor="PRR"> <tile_lay tile="9" location="H14" orientation="SW"> </action> etc.? Erik. |
|
From: Brett L. <wak...@ea...> - 2005-03-06 21:43:19
|
>> 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. |
|
From: Stewart T. <wsr...@ho...> - 2005-03-07 10:50:51
|
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_id396&op=click >_______________________________________________ >Rails-devel mailing list >Rai...@li... >https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Brett L. <wak...@ea...> - 2005-03-07 18:08:13
|
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. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X