Thread: [Rails-devel] Making Rails more suted to fast interactive play. Was [18xx] Programing a Windows 18X

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

   There was a lively discussion on the 18xx list as to how to make Rails a faster game for electronic interactive play.  Certainly the recent addition of 'reload' helps a lot.  Thanks!   However in the 18xx list John Tamplin was saying that Rails is simply too clunky for good interactive play.  Other people were saying, bah, Rails works fine with Dropbox or similar services.  Some of the conversation is quoted below in case you wish to review it.   I am going to take the middle road and say that Rails is clunky but with a few improvements it could be much better.

    In considering how people play, I suspect that all of us can agree that a player turn should consist of action(s) followed by a confirmation that the player turn is complete. In other words people should have the ability to consider the ramifications of their turn before committing to it. A possible exception are phases such as the initial round where the action is a simple single option (e.g., bid, buy or pass). 

    At least that is the way I play in real life.  In other words when a person is running a company the official order of play is often tile, token, calculate run, payment, train purchase.  If a person does a tile, etc. up to the point of purchasing a train and then decides that a different tile and withholding would allow him to purchase a train we allow him to rollback his turn.  We might groan but until he says "I'm done" then he has flexibility.

    With that in mind let us look at a typical player SR turn in Rails using Dropbox and see where the clunky parts are:

    1) Somehow detect that it is your turn (e.g., Dropbox pops up a notice of a new file or you notice a new file in the directory or your friends send you reminder email/phone calls/text messages)
    2) Select the 'reload' option (file location automatically generated; e.g., the Dropbox folder)
    3) Scroll down through a perhaps long list of previously saved turns and select a file.
    4) Click the 'open' button.
    5) Do buy/sells as desired, clicking those buttons.
    6) Click the 'done' button.
    7) Select the 'save' option.
    8) Click the 'save' button (file name and location automatically generated)

    While the above is fairly fast, and with the 'reload' option much faster than before when there was also the required steps of (9) close the program and (0) open the program, there are still a number of steps that could be eliminated.  Ideally a turn would look like:

     1) Rails notifies you that it is your turn; e.g. through a flashing icon on the rails window, via a taskbar flashing, audio, etc.
     5) You start off with current data (i.e., Rails has automatically loaded in the game file) in front of you; do buy/sells as desired.
     6) You click the 'done/save' button

    An elimination of many steps -- and perhaps more important the elimination of the repetitive boring steps.

    A similar argument could be made for ORs and initial rounds.  

    Now I am not offering to do the coding -- once again my unfamiliarity with Java and a lack of time to learn it are interfering -- however speaking as a non-Java programmer I can see that it should be straightforward to have (1) a combination 'done' and 'save' button plus (2) a background job inside Rails that would look for the proper incoming file in order to do 'reload', 'select', 'open', 'notify' actions.   Perhaps not easy to program but at least logical enough to program.

    Of course we would still want a way to run Rails without doing all of the automatic saving.  One strength of Rails is the ability to do 'what if' scenarios.

    I also do not wish to disparage John Tamplin's (and others) ideas about using Google Apps or similar in order to provide for a more intelligent client/server, cloud, HTML5 way of approaching the usability issues.  The above are more my thoughts on 'can we make Rails more usable with some tweaks' rather than a way of saying "this is the best way to do things."

-- Rick

----- Original Message -----
> Why do you have to upload it? If you load the file from Dropbox, it
> will by
> default save it in the same Dropbox folder.
> 
> Thus, it's simply:
> 
> load a game save file, click pass, save the game
> 
> Not going to get much easier than that without *significant* changes
> to
> Rails.
> 
> On a related note, the next version of Vassal will include a math
> engine. At
> that time, I hope to edit my Vassal mod to include the kind of
> automatic
> math functionality (minus route calculation) that is currently found
> in
> Rails.
> 
> Vassal supports live play as well as PBEM.
> 
> -Tim
> 
> 
> On Thu, Mar 10, 2011 at 4:50 PM, John A. Tamplin <ja...@ja...> wrote:
> 
> >
> >
> > On Thu, Mar 10, 2011 at 4:46 PM, Stefan Filonardi <jk...@gm...>
> > wrote:
> >
> > > Too slow?
> > >
> > > Rails with reload function + dropbox is almost faster than I can
> > > handle.
> > >
> >
> > So, have you ever played an on-line game? Think about during the
> > private
> > auction, I should just be able to click on pass and be done with it.
> > Having
> > to load a game save file, click pass, save the game, upload the file
> > just
> > seems primitive for an interactive game. I'm not saying you can't do
> > it,
> > but it is ridiculously slow and cumbersome compared to just playing
> > an
> > online game.
> >
> > --
> > John A. Tamplin
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> 

Thread: [Rails-devel] Making Rails more suted to fast interactive play. Was [18xx] Programing a Windows 18X

rails-devel