Re: [Rails-devel] A question or two about the Rails XML interface.

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

Thanks. 

I have created a (temporary) local branch for 1837 where I will collect the
initial bits and pieces.
Once the game can at least be started and show the map, I will merge that
branch into the master branch and push it to the repository so everybody can
access it.

I have already fixed some unterminated <LayTile> tags in Game.xml.

Next problem is that you have configured a number of game-specific classes
without providing these classes.  That prevents Rails from starting this
game.

Possibilities:
(1) What we normally do when developing a new game is that we begin with the
generic classes only, and only add new ones when the need clearly arises
during development.
(2) As 1837 presents itself as "a development of 1835", we could also start
with the 1835 classes, which could then be modified or extended.  But that
is a bit dangerous (for 1835), and not my preference.
(3) I could also create empty 1837-specific classes according to what you
have configured.  These could be filled in later where needed, removed if
unused, or merged with their 1835 siblings where it appears that
generalization is possible.

It seems to me, that the 1835 UI classes can be reused unchanged or with
minimal changes. On the server side things are less obvious, so we will have
to see how that goes.

Did you have any particular route in  mind?  Otherwise I'll follow path (1)
and remove the _1837 name parts initially, so we can at least see something
happening.

In the meantime, I'll try to make initial versions of the 1837 special tiles
and the map.

Erik.

> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]
> Sent: Sunday, May 13, 2012 7:54 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] A question or two about the Rails XML
interface.
> 
> On 2012-05-12 15:45, Erik Vos wrote:
> >> I'm going to treat the mines as offboard destinations for calculating
> >> runs, which means I need a way to specify that the G trains must
> >> start "offboard" and all others can't go there.  Graphically, I
> >> intend them to look like the actual board (which means that the coal
> >> company's token, which will exist for calculating runs, needs to be
> invisible).
> 
> > Not sure how to handle inaccessibility based on train type (or train
class).
> > I guess Stefan will have to write some special code for that.  A way
> > to make it generic would be fine, as other games need this feature as
well.
> 
> To limit what trains a company can own, I suggest an attribute within
either
> Company or CompanyType of the form
>    <Train canOwnTypes="1G,2G,3G,4G">
> 
> But to limit access to map hexes by train type is harder.  Maybe you're
right
> and "mine" should be its own type of stop (in which case we would declare
> the passenger trains as not being allowed to go there, and the goods
trains as
> needing to have exactly one mine on their run).
> 
> At any rate, here is what I have so far for the six XML files under
/1837/data.
> Game.xml is particularly incomplete.  I have the feeling that the whole
> "merge minor companies into the Prussian" sequence from 1835 is going to
> move from being game-specific to the common code base, where other
> games (18MEX?
> 2038 someday?) will use it, too.  9 of the 10 major companies in 1837 have
at
> least one company that merges into them!
> 
> I'd like to see what the tile set looks like after TileManager is finished
with
> them.  I'll probably need to correct half the orientations in Map.xml.