Re: [Rails-devel] Redo & 1835

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

On 7/29/06, Erik Vos <eri...@hc...> wrote:
> > > A selection box after selecting 1835 will now ask for the opening
> > > variant to play: Standard, Clemens or Snake. The Start
> > round variants
> > > work, except for some validation rules (cash!).
> >
> > Rather than a separate pop-up, I think we should include this in the
> > Options dialog.
> >
> > I think some sort of "when game X is selected, we populate the dialog
> > with the available options" mechanism would work.
>
> Fine with me, but I'll leave the work to you, if you don't mind.
> You can find in Options how I populate the selection.
>

Sure.  I can do that.

> > > I have chosen this game because (1) it's already partly done,
> > > (2) it adds some interesting new game aspects, and (3) the
> > > extra's are probably not too difficult to implement.
> > > In particular, there are no special private properties
> > > beyond what we already have (except for the Prussian formation).
> > > It is a well-known game too, at least in Europe...
> > >
> >
> > Sounds good to me.  Will coding the Prussian formation be generic
> > enough to also handle the CNR in 1856?  Or are there specifics about
> > each that might require special-case coding?
>
> It is very different. In 1856, the CGR is formed from other
> major companies under certain conditions, and it is an automatic process.
>
> OTOH, in 1835 the Prussian forms out of minors and privates,
> and players have several occasions to decide if they want to convert or
> not, first at the start of the first 4-train, and then further
> at the start of each SR and OR.
> I will try to reuse the existing M&H/NYC swap mechanism to implement
> a first version of this process.
>

Ok... I haven't played 1835, so I wasn't really sure if it was at all
similar to any other game.

> > > Another simple game that should be easily doable is 1851;
> > > only the start round needs extra coding.
> > >
> >
> > Is there an easy way we can differentiate between playable and
> > unplayable games in our UI?  Right now, users have no way of knowing
> > what isn't fully implemented until they try to play it.
> >
> > I suspect this may require changing how we populate the game list, but
> > perhaps that might be a good thing for a few different reasons.
>
> Yes, that is a very good suggestion.
> Rather than looking for subdirectories of 'data' we could put a
> 'catalogue' file in that directory. That file could contain
> a list of games with a status value for each game.
> Status values could be:
> - Playable (or finished)
> - Partly playable (or unfinished)
> - Unplayable (under development)
>
> Options could include a selection of what minimum status level
> should be applied. On publication, this should be preset to 'playable'
> (but of course I will set it much lower).
>
> We also need a properties file to store parameters
> like this preset level, language etc.
>


I like that.  Let's do this.


---Brett.