Menu
▾
▴
rails-devel
|
From: Chris S. <chr...@gm...> - 2009-11-09 17:25:37
|
Before I try it, I thought I'd ask - has anyone tried simultaneously loading a game from two different computers while using Dropbox as the game save file location? If one player makes an action, would it update in the other player's copy of the open game file? Or am I just asking for trouble? -- Chris Please consider the environment before printing this e-mail. |
|
From: brett l. <wak...@gm...> - 2009-11-09 17:29:18
|
On Mon, Nov 9, 2009 at 9:25 AM, Chris Shaffer <chr...@gm...> wrote: > Before I try it, I thought I'd ask - has anyone tried simultaneously loading > a game from two different computers while using Dropbox as the game save > file location? If one player makes an action, would it update in the other > player's copy of the open game file? Or am I just asking for trouble? I would expect that very little happens. The save file is read only at load-time. After that, it's not read again. The only time the file is written is when a user saves the game. If you can coordinate each user loading the new saved game, I suspect you could effect a sort of low-tech networked play. > > -- > Chris > > Please consider the environment before printing this e-mail. ---Brett. |
|
From: Chris S. <chr...@gm...> - 2009-11-09 17:32:48
|
> > 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. Chris |
|
From: Jim B. <jim...@ya...> - 2009-11-09 18:06:51
|
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
|
|
From: Jim B. <jim...@ya...> - 2009-11-09 18:09:37
|
PS. My (d) item was a little incomplete, below. That is, we have an
archive sub-folder within each game folder- periodically we just
select a bunch of the oldest "recent moves", and move them all into
that subfolder. So, the housekeeping is pretty easy, and we browse
fairly short lists of [only] recent moves during typical play/etc.
On Nov 9, 2009, at 10:06 AM, Jim Black wrote:
>
> 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
>
>
|
|
From: Erik V. <eri...@hc...> - 2009-11-12 19:19:10
|
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
|
|
From: brett l. <wak...@gm...> - 2009-11-12 19:24:25
|
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
>
>
|
|
From: Erik V. <eri...@hc...> - 2009-11-12 22:40:42
|
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
|
|
From: Chris S. <chr...@gm...> - 2009-11-13 02:08:34
|
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
>
|
|
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
|
|
From: Jim B. <jim...@ya...> - 2009-11-09 18:20:10
|
PPS- also, chris- it occurs to me that the approach I described with the separate, empty "current player token" file can be viewed as a "lock file" for the game- whoever "owns" that token file (ie, whoever the file is named after), is the current player that's writing to the rails folder, in general. When that player finishes, he renames the file to point to the next player - and, essentially, has thus handed the "write lock" over to the subsequent player, too. It hasn't really come up for us that we had the opportunity for write conflicts on the same files (and, even if we do housekeeping simultaneously- simple renames and moves- it's fairly harmless, even if there is an unlikely collision). But, this might provide additional practical benefits from decoupling the actual 'save file' (a .rails extension file, holding game state) from the 'current player' file (an empty file, renamed by convention to identify the current-player, and stand-out at the top of the browser list). best, - jim On Nov 9, 2009, at 9:25 AM, Chris Shaffer wrote: > Before I try it, I thought I'd ask - has anyone tried simultaneously > loading a game from two different computers while using Dropbox as > the game save file location? If one player makes an action, would > it update in the other player's copy of the open game file? Or am I > just asking for trouble? > > -- > Chris > > Please consider the environment before printing this e-mail. > ------------------------------------------------------------------------------ > 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 |
|
From: Chris S. <chr...@gm...> - 2009-11-09 18:27:32
|
Yeah, we tried that, but renaming the file doesn't "touch" the timestamp in
Linux.
Good system though. What I'm hoping is that eventually we can get it to
push updates to the other players' clients, so we can play near-realtime
online.
--
Chris
Please consider the environment before printing this e-mail.
On Mon, Nov 9, 2009 at 10:06 AM, Jim Black <jim...@ya...> wrote:
>
> 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
>
>
|
|
From: Jim B. <jim...@ya...> - 2009-11-09 18:39:55
|
Chris, Thanks for the followup- > Yeah, we tried that, but renaming the file doesn't "touch" the timestamp in Linux. Bummer. I always open the file and write it back (to coerce the update), and the move file is being saved at the same time anyway- but that's a good point, because- > Good system though. What I'm hoping is that eventually we can get it to push updates to the other players' clients, so we can play near- realtime online. One major disadvantage of the approach I'm using, vs yours, is that the update of the 'rails save file' and the 'current player token' file is not atomic- a player can do one, but forget the other, etc. Or, a player might save his move, but before he sends email and updates the token, he begins to reconsider. Not a good situation- as someone else might now be assume the move is played (given the notification of the saved move, in the dropbox). We did it the other way- the same file- with Steam, for a while, when using VASSAL. But, people were always screwing up the turn-order and making mistakes- which is why we started keeping them separate. VASSAL didn't maintain turn-order at all, though- players did. Rails, by contrast, maintains turn-order properly. So, maybe this isn't really a problem, anymore- and I should try it your way, again. :-) - jim |
×
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