From: Erik V. <eri...@hc...> - 2009-11-13 23:28:22
|
Yes, you're right, that's much better. Erik. _____ From: Chris Shaffer [mailto:chr...@gm...] Sent: Friday 13 November 2009 02:40 To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] Simultaneous loading of a game One potential problem I see is that you wouldn't be able to load the game during another player's turn. Perhaps instead of refusing to open or save, you could give a warning instead? We occasionally have someone reply from their phone email that they want to "buy a share of FS" and then the next player actually implements their action for them. That way, we don't have to wait for the guy who is on the bus or at the restaurant to get back to his computer to actually take the turn. -- Chris Please consider the environment before printing this e-mail. On Thu, Nov 12, 2009 at 2:40 PM, Erik Vos <eri...@hc...> wrote: It sounds OK to me to have a flag that enables or disables "dropbox" mode. But there is a little bit more to it, I think. Let me try. We will also need a "Game name" parameter that identifies the particular game instance being played. Just any string. I suppose this should also be an option to be set at game start. Both options should also be added to the saved file itself, so that these can be automatically be picked up on loading a saved file. And that without affecting backwards compatibility... The (current) startup Options button only handles gameplay-affecting options. Not sure if we should add these options of a different kind to that; I think we can better these keep these separate. We could extend the Options menu in the GameStatus window, or add an extra button to the startup window. We need at least one extra configuration parameter in my.properties: the location of the "player token" file. Perhaps also a default dropbox-mode setting? Other aspects might also become configurable, but perhaps we can as well hardcode these: - the player suffix - always just the saving player name? - the common time zone - fix to UTC? The (as yet unautomated) process will be, if dropbox mode is set: - On saving a file: - Check if the player has the turn, by inspecting if a player token file exists with a name equal to the saving player name. If not, saving is refused. - The file will be saved, with the current player name inserted in the file name after the time stamp. - The token file will be renamed to the next player having the turn. - On loading a file: - Check if the player has the turn, by inspecting if a player token file exists with a name equal to the loading player name. If not, loading is refused. Any comments? Erik. > -----Original Message----- > From: brett lentz [mailto:wak...@gm...] > Sent: Thursday 12 November 2009 20:24 > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Simultaneous loading of a game > > Yeah, this could easily be a checkbox in the startup options. > Something along the lines of "PBEM (via Dropbox)" > > ---Brett. > > > > On Thu, Nov 12, 2009 at 11:18 AM, Erik Vos <eri...@hc...> wrote: > > Fascinating. > > > > I'm thinking: > > > > 1. Would it be possible to describe this/these process(es) > in a HOW-TO > > document that Brett perhaps could publish on the Rails > Sourceforge website, > > so that other (potential) users could easily reuse it? > > > > 2. What could be added to Rails to facilitate this process? I think > > writing/renaming a token file and adding a player-specific > postfix to the > > save file name would be easy to implement, perhaps even be > included in > > 1.0.7. However, that would require writing down > specifications pretty > > quickly. We could also plan another new release pretty soon > after 1.0.7. > > > > 3. Further automation (such to do all this automatically at > each turn > > change, and perhaps even polling the dropbox) could be added later, > > effectively creating a poor man's network playing facility indeed. > > > > I must say: the idea of not having to worry about > overhauling the code to > > create real networking in the near future (a much wanted > facility) would > > save us enormous amounts of time to invest in other new features. > > > > Regards, > > Erik. > > > > ________________________________ > > From: Jim Black [mailto:jim...@ya...] > > Sent: Monday 09 November 2009 19:07 > > To: Development list for Rails: an 18xx game > > Subject: Re: [Rails-devel] Simultaneous loading of a game > > > > > > On Nov 9, 2009, at 9:32 AM, Chris Shaffer wrote: > >> > >> If you can coordinate each user loading the new saved > game, I suspect > >> > >> you could effect a sort of low-tech networked play. > > > > Yeah, that's effectively what we have now. We save and > append the next > > player's name to the save file, they see dropbox update the > file and see > > their name in the filename and know its their turn. > > > > works like that here too, but here's the save protocol we > use (similar, but > > different) - > > a) use UTC option so timestamps sequence properly > > b) each player appends his-own-name to the save-file > ('-jb', or whatever) > > c) there's an empty file in the folder, representing the > "current player" > > token. whenever someone moves, they update this empty > file, and rename it > > to point to the next player. > > d) we also have an "archive" subfolder for each game folder, > > Other details: > > i. This approach for initialing your own save-file ((b), > above), makes it > > easier to find/identify particular saved moves. > > ii. To supplement (b) and (d) for the game archive, I also > drop other > > empty/placeholder files in the folder, as bookmarks for the SR/OR > > transitions. > > iii. All these files are named appropriately (with the > game prefix), so > > that they all sequence in folder-browsing (from Rails, from > browsing folders > > externally, etc), with the "current move" token at the very end. > > iv. Thus, I can always & quickly browse the current > folders in my dropbox > > (one per active game), see a short listing of the recent > moves for each, > > with the "current player" named at the end. > > In this way, we get a decent archive (easy to browse the > archive subfolder, > > and identify key phases too- sr2, or3.1, etc), the > current-player signaling > > stuff ("token files") remains separate from the .rails move > stuff ("save > > files"), and notifications are easily both "pushed" (by dropbox > > notifications when a move or token is updated), and > "pulled" (naming and > > archive conventions that make the folders very quick to > browse, to review > > current game states). > > Anyway, I thought I'd share this in case any of its helpful to you. > > - jim > > > > > > > -------------------------------------------------------------- > ---------------- > > Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 30-Day > > trial. Simplify your report design, integration and > deployment - and focus > > on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > -------------------------------------------------------------- > ---------------- > Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 30-Day > trial. Simplify your report design, integration and > deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |