rails-devel

Re: [Rails-devel] Coalfields and states

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

Erik:
To solve the issue of the location I would simply add a location field to the
SpecialRights class and initialize that from XML.

I am not an expert on those special properties etc., but it seems that only 
store the rights inside PublicCompany classes to be able to show it in the UI.
For the revenue calculation there is no need this could be replaced by 
allowing to figure out the owner of the special property from inside (e.g. 
adding a field owner) and adding a boolean field purchased.
Stefan

On Thursday, July 07, 2011 10:19:21 am Erik Vos wrote:
> Thanks, Stefan.
> 
> > A) Reading the rules carefully it seems that the rights are only required
> 
> for
> 
> > the revenue train run, not for tracing a route for tile and token laying.
> 
> Do all
> 
> > agree on this?
> 
> I would agree, but that's more because of the simplicity of interpreting
> the rules this way than that I'm any sort of rules expert....
> 
> > B) Suprisingly (to me at least) SpecialRights has to no location field,
> 
> thus I had
> 
> > to hardcode the coalfield hex location. On the other hand I did not know
> > what to do with fields rightValue and rightDefaultValue.
> 
> Ah, good point.
> I had created Rights as a map so it could be used for more complex cases,
> but the value is currently unused and remains null.
> Would it help to use the location name as the value of this right? Any
> other ideas?
> 
> In addition: would it be useful to give this hex (or HexStation) a special
> type once we have implemented that new concept?
> Here we could reuse type "mine", because that's a pretty generic type that
> occurs in several games.
> 
> > C) The finishConfiguration method of SpecialProperties for a
> > (Public)Company were not called. I added the missing call to the
> > finishConfiguration of PublicCompany. I have not checked if this call is
> 
> also
> 
> > missing for PrivateCompany and/or should be better moved up to the
> > Company class.
> 
> OK, I'll have a look.  Yesterday I had the same problem with Phase.
> 
> finishConfiguration() is intended to be generic in all configurable
> classes, but it's an afterthought and is so far only called where it is
> really used (and apparently not even that!).
> 
> > D) Personally I am not too happy that the main code parts of Rights
> > (which
> 
> in
> 
> > my view is not a very general part of 18xx) are  inside the main classes
> > PublicCompany and OperatingRound, which are already difficult to
> > understand and in my view have grown too large.
> 
> Well, right.  But otherwise specific OperatingRound_1830 and
> PublicCompany_1830 classes would be needed to implement this feature, and I
> found that a bit of overkill too.  But it's still an option. Would you have
> preferred that approach?  The SpecialRight class would then also become
> specific and be renamed to CoalfieldsRight or so.
> 
> I have no idea in what other games we could use Rights. As I have named it,
> it's very generic and could perhaps be employed in currently unexpected
> ways. But I must admit that I can't give any example, so maybe you're
> right.
> 
> > But breaking up the Round
> > classes has been on my agenda for long and I know that Erik is not happy
> > about that idea neither ;-)
> 
> That could be so because of my rusty brains, of course.  It's not so that I
> would run away if you started doing such things.  But I think that it will
> be (1) a hell of a lot of work, and (2) pretty dangerous.
> 
> Erik.
> 
> 
> 
> ---------------------------------------------------------------------------
> --- 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

Re: [Rails-devel] Coalfields and states

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

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.

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