Re: [Rails-devel] Coalfields and states

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

Interfaces are fine, but the trouble is that these must be implemented
somewhere. (I realise that you may have used the word 'interface' in a more
general sense, but let's then say: processes must be coded somewhere).

For now it's a matter of all or nothing, in other words: in the core or in a
game-specific class.  Do we have any other flavours?  

I think it's pretty pointless to try creating class hierarchies. Perhaps we
haven't done enough games yet, and one could think of common classes for
1830-style games, 1829-style games, OO games, etc., but I'm not really
convinced that such approaches would help us much. 

And I'm firmly against code duplication on a larger scale than the
unavoidable.  That's mainly why processes that occur in more than one game
tend to end up in the core.  And, indeed, I also tend to let slip through
very simple actions that are unique but take little code and therefore IMO
don't warrant creating game-specific classes on their own (but I'm willing
to change mind on this last point).

Perhaps your new grand scheme has a solution for all of this, but until we
have got a better idea of how that scheme looks like and works, the above is
the only way I can think about how to incorporate new features.

My mails are always too long, so I'll better defer my specific comments on
Rights to another one.

Erik.

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]
> Verzonden: vrijdag 8 juli 2011 9:59
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Coalfields and states
> 
> Here I would disagree for me it seems possible to model the Rights part of
> the Mesabi Range using the same class as Coalfields. However it will need
> further adjustments (of the same or other classes) to capture the full
ruling.
> 
> My main take is to keep the core code clean (and by this stable) for the
core
> rule set. This requires two things:
> 
> A) Defining what is the core code and provide Interfaces where special
rules
> can interact.
> 
> My current rule of thumb for the Rails code is that everything not called
> specific or special is current core code. And for me it contains code
which
> does not belong there, for example the support of Rights in OR and
> PublicCompany.
> Another example is some of code required for 1856.
> 
> B) Identify which are core rules/components.
> 
> My rule of thumb here is that core rules/components are those which are
> used by almost all games. (Almost all means except all except a few, taken
> from Probability Theory ;-)). All other rules are special/specific rules.
> 
> Examples for core rules/components are the existence of Corporations that
> lay tiles and tokens and are owner of trains and run those trains from
tokens
> on track defined by those tiles.
> 
> Usually the non-core rules are not that stable, so quite often they are
> substantially different in details. Examples are Merger rules.
> 
> As always there is not always black-and-white (define few?) but that is up
to
> us then to decide.
> 
> Important: This is not set in stone. If we identify mechanism which are
used
> so often and so stable that the qualify as core rules, the code of that
can be
> upgraded into the core code part. If we need further interfaces to
> incorporate new rules of yet unimplemented games or even yet uninvented
> games we identify those and add according interfaces to the core code.
> 
> The text got longer than intended, but that there my thoughts how to
design
> the RevenueCalculation package: Define the core part and then add
> interfaces to adopt  to the various little details.
> So I am curious how others think about that.
> 
> Stefan
> 
> 
> On Thursday, July 07, 2011 09:39:14 pm Erik Vos wrote:
> > So that makes two, but this one is sufficiently different to require a
> > special class anyway, so perhaps we should go that way for 1830
> > Coalfields as well, as Stefan implies.
> >
> > Erik.
> >
> >
> >
> > Van: Scott Petersen [mailto:sc...@re...]
> > Verzonden: donderdag 7 juli 2011 16:22
> > Aan: Development list for Rails: an 18xx game
> > Onderwerp: Re: [Rails-devel] Coalfields and states
> >
> >
> >
> > Here is the rules section on 1850's Mesabi Range.
> >
> >
> >
> > 6.5.1 The Mesabi Range
> >
> > The Mesabi Range is a special grey hex. To run to or
> >
> > through the Mesabi Range a company must pay the $80
> >
> > cost for rights to the Mesabi Range. Paying for the Mesabi
> >
> > Range counts as a yellow tile lay.
> >
> > If the Mesabi Range private company has been closed, the
> >
> > money for the Mesabi range goes to the bank. If a public
> >
> > company owns the Mesabi Range private company, it receives
> >
> > half of the Mesabi Range connecting money with
> >
> > the rest going to the bank.
> >
> > The rights to the Mesabi Range may not be purchased until
> >
> > the Mesabi Range private company has been closed or
> >
> > sold to a public company. As there are only four Mesabi
> >
> > tokens, only four companies may have the rights to the
> >
> > Mesabi.
> 
>
----------------------------------------------------------------------------
--
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel