rails-devel

[Rails-devel] Implementation levels

[Stefan F. <ste...@we...>]

After some discussion with Erik and Brett how to assign the playability of the 
variants I am supporting now, I tried to assign some definitions to each 
level of implementation. 

As Erik already remarked, there none of the variants fits into A) for now, but 
that is hardly surprising given that Rails is still in beta.

I would be glad to hear more opinions on both the categories themselves and 
how to assign the current supported 18xx variants.

Stefan

My suggestions are:
1870 - D
1889 - B

Implementation Levels:

A) Mature
- Several independent plays until the end reported
- Full implementation of the ruleset
- All possible moves are available
- No illegal move possible (except tile and token lays, revenue calculation)
=> Serious ftf play possible
=> pbem play possible

B) Fully Playable
- Full implementation of the ruleset
- All possible moves are available
- Might still allow a few illegal moves (in addition to tile and token lays, 
revenue calculation)
=> Serious ftf play possible, but bugs are possible
=> use with caution for pbem play, version incompatibilities possible

C) Almost Playable
- Nearly complete implementation of the ruleset
- Not all possible moves are available
- Illegal moves are possible
=> Serious testing possible, do not expect to complete a game
=> not recommended for pbem play

D) Experimental
- Rules and components are incomplete
=> Some testing possible

Re: [Rails-devel] Implementation levels

[Phil D. <de...@gm...>]

Stefan,

I think your definitions are pretty good, although under B, you put
'version incompatibilities possible'.  Theoretically with the amount
of shared code that impacts across multiple games and the shared tile
database, version incompatibilities could always creep in?  Obviously
we would want to minimise them but I think it's not unreasonable to
expect people to use a consistent version for their games.

For existing support levels, my opinions:
1825: D
1830: B (Can you swap the M&H at any time now?  A bugfix release that
resolves the private swap bug might put this very close to A)
1851: B
18AL: B
18EU: C/B (I had a lot of issues in 1.1.3, I should retry a game in
1.2 to see how the bugfixes hold up

Phil


On 16 March 2010 22:33, Stefan Frey <ste...@we...> wrote:
> After some discussion with Erik and Brett how to assign the playability of the
> variants I am supporting now, I tried to assign some definitions to each
> level of implementation.
>
> As Erik already remarked, there none of the variants fits into A) for now, but
> that is hardly surprising given that Rails is still in beta.
>
> I would be glad to hear more opinions on both the categories themselves and
> how to assign the current supported 18xx variants.
>
> Stefan
>
> My suggestions are:
> 1870 - D
> 1889 - B
>
> Implementation Levels:
>
> A) Mature
> - Several independent plays until the end reported
> - Full implementation of the ruleset
> - All possible moves are available
> - No illegal move possible (except tile and token lays, revenue calculation)
> => Serious ftf play possible
> => pbem play possible
>
> B) Fully Playable
> - Full implementation of the ruleset
> - All possible moves are available
> - Might still allow a few illegal moves (in addition to tile and token lays,
> revenue calculation)
> => Serious ftf play possible, but bugs are possible
> => use with caution for pbem play, version incompatibilities possible
>
> C) Almost Playable
> - Nearly complete implementation of the ruleset
> - Not all possible moves are available
> - Illegal moves are possible
> => Serious testing possible, do not expect to complete a game
> => not recommended for pbem play
>
> D) Experimental
> - Rules and components are incomplete
> => Some testing possible
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Implementation levels

[brett l. <bre...@gm...>]

On Wed, Mar 17, 2010 at 9:58 AM, Chris Shaffer <chr...@gm...> wrote:
>> I agree, somewhat.  I think the assumption should just be to finish a
>> game with the same version of Rails that started the game.
>>
>> Until the codebase matures a bit, I don't really think it's worthwhile
>> to spend a ton of effort worrying about save file compatibility.
>
> The one concern I have with this is showstopper bugs.  If a group is playing
> a game, gets halfway through, and can't continue because of a bug, there
> should be some support for converting their game to the new version with the
> bugfix.
>
> --
> Chris


Of course.   I'm not saying that we won't support users when they have
problems.  We absolutely should and will.

I'm saying that, as developers, we shouldn't spend a lot of time
trying to preserve backwards compatibility with old save formats. It's
extra work that just doesn't buy us anything at this stage in rails'
maturity.

If the number of safe files that we need to migrate forward to the new
format grows substantially, obviously we'll need to change this
strategy or develop tools to allow users to migrate save files. For
now, I'd just like to see bug fixes and new games/features take a
higher priority than save file compatibility.

---Brett.

Re: [Rails-devel] Implementation levels

[Erik V. <eri...@xs...>]

Save file compatilibity is important for regression testing, as long we
don’t have better ways to retest existing functionality than by loading old
saved files (at least I don't). Several classes have extra code to cope with
that. One day we might decide to take the hit and clean up all such code,
but IMO that should be a conscious decision. Fortunately, the main thing to
do about that is making sure that PossibleAction subclasses can still
deserialize when extra attributes have been added.

These days, most incompabilities arise as a consequence of bug fixing. This
might make old moves illegal (for instance, when the order of operation of
companies has changed). Another recent example is the inclusion of an extra
action to select the home city on a OO tile (1830 Erie, 1856 THB). The only
option to resume such a broken game with a new version is replaying the game
from the start, or from a file saved just before the cause of the change.

Erik.

-----Original Message-----
From: brett lentz [mailto:bre...@gm...] 
Sent: Wednesday 17 March 2010 18:14
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation levels

On Wed, Mar 17, 2010 at 9:58 AM, Chris Shaffer <chr...@gm...>
wrote:
>> I agree, somewhat.  I think the assumption should just be to finish a
>> game with the same version of Rails that started the game.
>>
>> Until the codebase matures a bit, I don't really think it's worthwhile
>> to spend a ton of effort worrying about save file compatibility.
>
> The one concern I have with this is showstopper bugs.  If a group is
playing
> a game, gets halfway through, and can't continue because of a bug, there
> should be some support for converting their game to the new version with
the
> bugfix.
>
> --
> Chris


Of course.   I'm not saying that we won't support users when they have
problems.  We absolutely should and will.

I'm saying that, as developers, we shouldn't spend a lot of time
trying to preserve backwards compatibility with old save formats. It's
extra work that just doesn't buy us anything at this stage in rails'
maturity.

If the number of safe files that we need to migrate forward to the new
format grows substantially, obviously we'll need to change this
strategy or develop tools to allow users to migrate save files. For
now, I'd just like to see bug fixes and new games/features take a
higher priority than save file compatibility.

---Brett.

----------------------------------------------------------------------------
--
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation levels

[brett l. <bre...@gm...>]

On Wed, Mar 17, 2010 at 5:20 AM, Phil Davies <de...@gm...> wrote:
> Stefan,
>
> I think your definitions are pretty good, although under B, you put
> 'version incompatibilities possible'.  Theoretically with the amount
> of shared code that impacts across multiple games and the shared tile
> database, version incompatibilities could always creep in?  Obviously
> we would want to minimise them but I think it's not unreasonable to
> expect people to use a consistent version for their games.


I agree, somewhat.  I think the assumption should just be to finish a
game with the same version of Rails that started the game.

Until the codebase matures a bit, I don't really think it's worthwhile
to spend a ton of effort worrying about save file compatibility.

---Brett.

Re: [Rails-devel] Implementation levels

[Chris S. <chr...@gm...>]

>
> I agree, somewhat.  I think the assumption should just be to finish a
> game with the same version of Rails that started the game.
>
> Until the codebase matures a bit, I don't really think it's worthwhile
> to spend a ton of effort worrying about save file compatibility.
>

The one concern I have with this is showstopper bugs.  If a group is playing
a game, gets halfway through, and can't continue because of a bug, there
should be some support for converting their game to the new version with the
bugfix.

--
Chris

Please consider the environment before printing this e-mail.

Re: [Rails-devel] Implementation levels

[Stefan F. <ste...@we...>]

Phil,
with respect to 18EU:

Which issues did you run into? From my only true ftf test game we only 
experienced the usual undo-related ones (which should be a thing of the past 
hopefully) and the wrong bankruptcy scenario, which stopped our play 
eventually.

I do not know if 18EU belongs to the category of those games where no player 
should ever go bankrupt (as in 1835), and we (or at least the one who went 
bankrupt) did something out of the norm.

Stefan


On Wednesday 17 March 2010 13:20:44 Phil Davies wrote:
> Stefan,
>
> I think your definitions are pretty good, although under B, you put
> 'version incompatibilities possible'.  Theoretically with the amount
> of shared code that impacts across multiple games and the shared tile
> database, version incompatibilities could always creep in?  Obviously
> we would want to minimise them but I think it's not unreasonable to
> expect people to use a consistent version for their games.
>
> For existing support levels, my opinions:
> 1825: D
> 1830: B (Can you swap the M&H at any time now?  A bugfix release that
> resolves the private swap bug might put this very close to A)
> 1851: B
> 18AL: B
> 18EU: C/B (I had a lot of issues in 1.1.3, I should retry a game in
> 1.2 to see how the bugfixes hold up
>
> Phil
>
> On 16 March 2010 22:33, Stefan Frey <ste...@we...> wrote:
> > After some discussion with Erik and Brett how to assign the playability
> > of the variants I am supporting now, I tried to assign some definitions
> > to each level of implementation.
> >
> > As Erik already remarked, there none of the variants fits into A) for
> > now, but that is hardly surprising given that Rails is still in beta.
> >
> > I would be glad to hear more opinions on both the categories themselves
> > and how to assign the current supported 18xx variants.
> >
> > Stefan
> >
> > My suggestions are:
> > 1870 - D
> > 1889 - B
> >
> > Implementation Levels:
> >
> > A) Mature
> > - Several independent plays until the end reported
> > - Full implementation of the ruleset
> > - All possible moves are available
> > - No illegal move possible (except tile and token lays, revenue
> > calculation) => Serious ftf play possible
> > => pbem play possible
> >
> > B) Fully Playable
> > - Full implementation of the ruleset
> > - All possible moves are available
> > - Might still allow a few illegal moves (in addition to tile and token
> > lays, revenue calculation)
> > => Serious ftf play possible, but bugs are possible
> > => use with caution for pbem play, version incompatibilities possible
> >
> > C) Almost Playable
> > - Nearly complete implementation of the ruleset
> > - Not all possible moves are available
> > - Illegal moves are possible
> > => Serious testing possible, do not expect to complete a game
> > => not recommended for pbem play
> >
> > D) Experimental
> > - Rules and components are incomplete
> > => Some testing possible
> >
> >
> > -------------------------------------------------------------------------
> >----- Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>--- Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation levels

[Phil D. <de...@gm...>]

Yeah, Undo issues aplenty, as well as some odd issues with a saved
game that constantly got corrupted with the first company formation
post phase 5 (it didn't seem to save the home city in the save file).
Also the issues we had previously with Pullmans getting force
discarded incorrectly.  These were either with version 1.1.2 or a
saved file I brought forward so I didn't log bugs for them since I
wanted to run through the gamesteps again in the newer version and see
if some of the bug fixes had resolved some of them.

You can go bankrupt in 18EU, what should happen is that all remaining
holdings for that player go to the pool, presidency transfers to a new
president if applicable, if not the company closes and the player is
eliminated from the game.  In practice this has only happened once to
me in a f2f game and we decided to just call it based on net worth of
the remaining players but in theory you should carry on with that
player eliminated.

On 17 March 2010 22:25, Stefan Frey <ste...@we...> wrote:
> Phil,
> with respect to 18EU:
>
> Which issues did you run into? From my only true ftf test game we only
> experienced the usual undo-related ones (which should be a thing of the past
> hopefully) and the wrong bankruptcy scenario, which stopped our play
> eventually.
>
> I do not know if 18EU belongs to the category of those games where no player
> should ever go bankrupt (as in 1835), and we (or at least the one who went
> bankrupt) did something out of the norm.
>
> Stefan
>
>
> On Wednesday 17 March 2010 13:20:44 Phil Davies wrote:
>> Stefan,
>>
>> I think your definitions are pretty good, although under B, you put
>> 'version incompatibilities possible'.  Theoretically with the amount
>> of shared code that impacts across multiple games and the shared tile
>> database, version incompatibilities could always creep in?  Obviously
>> we would want to minimise them but I think it's not unreasonable to
>> expect people to use a consistent version for their games.
>>
>> For existing support levels, my opinions:
>> 1825: D
>> 1830: B (Can you swap the M&H at any time now?  A bugfix release that
>> resolves the private swap bug might put this very close to A)
>> 1851: B
>> 18AL: B
>> 18EU: C/B (I had a lot of issues in 1.1.3, I should retry a game in
>> 1.2 to see how the bugfixes hold up
>>
>> Phil
>>
>> On 16 March 2010 22:33, Stefan Frey <ste...@we...> wrote:
>> > After some discussion with Erik and Brett how to assign the playability
>> > of the variants I am supporting now, I tried to assign some definitions
>> > to each level of implementation.
>> >
>> > As Erik already remarked, there none of the variants fits into A) for
>> > now, but that is hardly surprising given that Rails is still in beta.
>> >
>> > I would be glad to hear more opinions on both the categories themselves
>> > and how to assign the current supported 18xx variants.
>> >
>> > Stefan
>> >
>> > My suggestions are:
>> > 1870 - D
>> > 1889 - B
>> >
>> > Implementation Levels:
>> >
>> > A) Mature
>> > - Several independent plays until the end reported
>> > - Full implementation of the ruleset
>> > - All possible moves are available
>> > - No illegal move possible (except tile and token lays, revenue
>> > calculation) => Serious ftf play possible
>> > => pbem play possible
>> >
>> > B) Fully Playable
>> > - Full implementation of the ruleset
>> > - All possible moves are available
>> > - Might still allow a few illegal moves (in addition to tile and token
>> > lays, revenue calculation)
>> > => Serious ftf play possible, but bugs are possible
>> > => use with caution for pbem play, version incompatibilities possible
>> >
>> > C) Almost Playable
>> > - Nearly complete implementation of the ruleset
>> > - Not all possible moves are available
>> > - Illegal moves are possible
>> > => Serious testing possible, do not expect to complete a game
>> > => not recommended for pbem play
>> >
>> > D) Experimental
>> > - Rules and components are incomplete
>> > => Some testing possible
>> >
>> >
>> > -------------------------------------------------------------------------
>> >----- Download Intel&#174; Parallel Studio Eval
>> > Try the new software tools for yourself. Speed compiling, find bugs
>> > proactively, and fine-tune applications for parallel performance.
>> > See why Intel Parallel Studio got high marks during beta.
>> > http://p.sf.net/sfu/intel-sw-dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ---------------------------------------------------------------------------
>>--- Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>