rails-devel — List for discussion of Rails development

Re: [Rails-devel] Bonus Tokens & UI structure

[Brett L. <wak...@gm...>]

On Tue, 2007-12-04 at 22:04 +0100, Erik Vos wrote:
> A summary of the changes:
> 
> 1. The main goal was implementing bonus tokens,

An important feature of several games. Good choice. :-)


> Bonus tokens are not bound to stations (white circles). 
> To avoid conflicts with the current (imperfect) base token positioning, 

That's putting it mildly. ;-)

> In the future we will need some algorithm to find empty spots
> to lay such tokens (or perhaps predefine such spots in Tiles.xml).

Yes.  The token laying code needs a lot of love.  Perhaps there is someone 
lurking on the list that would like to work on it?


> 4. To get this all working was pretty much a nightmare, 
> not the least because of the complex and non-transparent
> structure of the OR UI code. To make a start improving this,
> I have added a new class ORUIManager, and moved most of the
> logic and state awareness into this class. The Window and Panel
> classes are now mainly concerned with UI updates and action
> catching, as they should (ORWindow, however, remains the main entry 
> point, for consistency with other round type UIs).
> 
> This restructuring work is far from complete, 
> but I think everything now at least works.
> 


We've restructerd the OR UI a few different times. I'm not certain
there's going to be an easy way to structure so many inter-dependent
parts.

Perhaps we just need to better document how it works so that each time
we come back to it, we don't have to RTFS over and over again to relearn
it.


> 5. One small fix related to the missing token names on the map.
> These were actually displayed, but in the wrong position:
> in the upper left corner of the map! This is now OK.
> However, the tokens are small and so the text is hardly readable.

Yeah, one of the bigger todo's that I've had on my list is to figure out
why the OR UI doesn't automatically re-size itself when the window is
resized. I suspect there's some single thing that's missing or
mis-configured that is causing it to stay a static size.



 ---Brett.


Ignorance must certainly be bliss or there wouldn't be so many people
so resolutely pursuing it. 

[Rails-devel] Bonus Tokens & UI structure

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

I have just committed a bunch of changes and a few new classes.

A summary of the changes:

1. The main goal was implementing bonus tokens,
in particular the 18AL +$10 Coalfield bonus token
that can be laid by a company owning the S&NA private.
Laying bonus tokens proceeds similarly as laying normal (base) tokens,
as outlined in the next points.

2. In the token laying step the S&NA owning company now has
a choice between two tokens that can be laid (in fact both can be laid,
as the bonus token is extra). So we need a selection mechanism.
I have implemented this similar to tile laying: after a hex is
selected, the tokens that can be laid on that hex (if any) are displayed
in the upgrade panel. If only one token can be laid, 
it is highlighted (light orange, as used in the stock round).
If there is a choice, none is highlighted initially, 
and the player must select one.

3. Bonus tokens can be laid at any time during the OR.
For that purpose, I have now added a "Special" menu to the OR window
(we already have such a Special menu in the stock round for e.g. the M&H/NYC
swap).
If a special action can be performed, such as laying a bonus token,
the Special menu is enabled and highlighted.

Bonus tokens are not bound to stations (white circles). 
To avoid conflicts with the current (imperfect) base token positioning, 
bonus tokens are laid near the upper left corner of a tile 
(a second one would be laid near the lower right corner).
In the future we will need some algorithm to find empty spots
to lay such tokens (or perhaps predefine such spots in Tiles.xml).

4. To get this all working was pretty much a nightmare, 
not the least because of the complex and non-transparent
structure of the OR UI code. To make a start improving this,
I have added a new class ORUIManager, and moved most of the
logic and state awareness into this class. The Window and Panel
classes are now mainly concerned with UI updates and action
catching, as they should (ORWindow, however, remains the main entry 
point, for consistency with other round type UIs).

This restructuring work is far from complete, 
but I think everything now at least works.

5. One small fix related to the missing token names on the map.
These were actually displayed, but in the wrong position:
in the upper left corner of the map! This is now OK.
However, the tokens are small and so the text is hardly readable.

Final comment:
Although I have not changed the Saved file structure and version number,
it appeared that some saved files can not be reloaded because of
a bug in saving token lay actions.

Erik Vos

[Rails-devel] New code

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

I have checked in some new stuff.

Most of it relates to the 18AL special properties,
that I have been working on in the past weeks.
The only visual change is that the Lumber Terminal
can now be placed under the correct conditions, but
behind the scenes a lot more preparational work 
has been done.

While at it, I have also done a few bits on 18EU:

1. The 18EU extra tiles have been added to TileDesigner.
For the preprinted tiles I have used the numbers 
assigned by Brett (i.e. -3005/-3011) to the tile 
images obtained from John.

2. A new generic Tiles.xml has been generated.
I have also added TileDesinger.18t to CVS, so that
other people might look at or perhaps work on this version 
of the tile data.

3. The 18EU map and tile XML files have been updated.
Of the preprinted tiles, only Paris and Berlin/Vienna
(-3005, -3006) have been used so far. The map tile
orientations have been added where required.
The map should now be about right.

4. I have also added initial versions of Game.xml
and CompanyManager.xml, so that 18EU now at least 
can be started, and the map can be inspected.
However, none of the 18EU-specific game mechanisms
have been implemented yet. For the initial round
I have reused the 1835 standard mechanism, where all
minors can be bought at a fixed price
(to get them all out, some prices should be lowered).

5. I have added two new optional attributes to the <Tile>
tag in TileSet.xml: 
'extId': the external Id, which is the tile number as printed
on the physical game tiles, to be shown in the UI and in messages. 
Not yet used.
'pic': the number of the picture to be loaded. 
Used for 18EU tiles (30)80-83.
For both, the 'id' is the default value.
I have dropped my previous idea to use the TileDesigner
'name' attribute for the external number; it is better
to keep this item free for textual information (such
as in which game a tile is used).

Loading 18EU gives exceptions while loading the 
Paris/Berlin/Vienna preprinted tiles -3005 and -3006: 

org.w3c.dom.DOMException: <unknown>:
The attribute "fill-rule" represents an invalid CSS value ("even-odd").
Original message:
The "even-odd" identifier is not a valid value for the "fill-rule" property.

	at org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(Unknown
Source)
	at org.apache.batik.css.engine.CSSEngine.getComputedStyle(Unknown
Source)
	at org.apache.batik.bridge.CSSUtilities.getComputedStyle(Unknown
Source)
... etc.

Apparently batik does not accept some of John's SVG.


Erik Vos
 

Re: [Rails-devel] 18EU Tile number overlaps

[John A. T. <ja...@ja...>]

On Fri, 26 Oct 2007, Erik Vos wrote:

> John, my version of TileDesigner (1.3.1 of 4 April 2004) cannot read your
> 18EU.18t.
> Lines starting with # or with CategoryCoord give error messages.
> Do you use a different version?

As I mentioned, I modified the format to include things I needed.  One of 
the things I added was #-lines for comments.  I added a number of fields 
and values that I needed to render the tiles properly.

I don't actually use TileDesigner to render the tiles, but my custom perl 
code which reads the modified TileDesigner format and generates 
Postscript. The perl internals were derived from the original Delphi code, 
but a number of rendering primitives were added and a Posctscript renderer 
was added to generate print-quality tile.  I sent the PS rendering code 
back to Marco, and I think he was working to integrate it into his Delphi 
code, but I haven't followed that closely.  Since then, I loaded the 
TileDesigner data into an Informix database which is my authoritive copy, 
and I have import/export tools to my modified .18t format.  The 
in-database version has additional data that was calculated on the fly by 
the layout code, so I could tweak it manually and mark it as no longer 
automatically generated.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] 18EU Tile number overlaps

[John A. T. <jat...@ja...>]

On Fri, 26 Oct 2007, Erik Vos wrote:

> John, my version of TileDesigner (1.3.1 of 4 April 2004) cannot read your
> 18EU.18t.
> Lines starting with # or with CategoryCoord give error messages.
> Do you use a different version?

As I mentioned, I modified the format to include things I needed.  One of 
the things I added was #-lines for comments.  I added a number of fields 
and values that I needed to render the tiles properly.

I don't actually use TileDesigner to render the tiles, but my custom perl 
code which reads the modified TileDesigner format and generates 
Postscript.  The perl internals were derived from the original Delphi 
code, but a number of rendering primitives were added and a Posctscript 
renderer was added to generate print-quality tile.  I sent the PS 
rendering code back to Marco, and I think he was working to integrate it 
into his Delphi code, but I haven't followed that closely.  Since then, I 
loaded the TileDesigner data into an Informix database which is my 
authoritive copy, and I have import/export tools to my modified .18t 
format.  The in-database version has additional data that was calculated 
on the fly by the layout code, so I could tweak it manually and mark it as 
no longer automatically generated.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] 18EU Tile number overlaps

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

> > What XML exported from TileDesigner are you referring to?  Is 
> > there a new 
> > version that supports XML?
> 
> I'm not aware that it is new...  
> The current version does have an export XML function.

John, my version of TileDesigner (1.3.1 of 4 April 2004) cannot read your
18EU.18t.
Lines starting with # or with CategoryCoord give error messages.
Do you use a different version?

Erik.

Re: [Rails-devel] 18EU Tile number overlaps

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

> > Our "database" is a big file named Tile.xml that has all the tiles
> > that currently exist in our version of the TileDesigner file.
> > I run the XML exported by TileDesigner through a utility that
> > extracts the connectivity information from it*.
> 
> What XML exported from TileDesigner are you referring to?  Is 
> there a new 
> version that supports XML?

I'm not aware that it is new...  
The current version does have an export XML function.

Erik.

Re: [Rails-devel] 18EU Tile number overlaps

[John A. T. <ja...@ja...>]

On Fri, 26 Oct 2007, Erik Vos wrote:

> Our "database" is a big file named Tile.xml that has all the tiles
> that currently exist in our version of the TileDesigner file.
> I run the XML exported by TileDesigner through a utility that
> extracts the connectivity information from it*.

What XML exported from TileDesigner are you referring to?  Is there a new 
version that supports XML?

> For now it seems to me, that I can best continue to create new
> tiles via TileDesigner for the purpose of XML creation,
> whereas Brett can meanwhile work with you to see if we can obtain
> better graphics that way.

I think you will find it easier to start with the TileDesigner data I 
provided (and can provide for most other games) and remove the extensions 
I added than to start from scratch, but however you want to do it is fine.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] 18EU Tile number overlaps

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

> Since Rails doesn't render the tiles from the tile data, it 
> seems like 
> most of that data is useless to Rails.  Also, I currently do not keep 
> information useful for route calculations which Rails will eventually 
> need, although I wouldn't be averse to extended it and 
> storing it as well. 
> Finally, I am more concerned with a unified database of all 
> tiles so I can 
> search for which games contain which tiles etc while Rails 
> doesn't care 
> for such a database (at least that is my recollection of a discussion 
> about this a couple of years ago).

Our "database" is a big file named Tile.xml that has all the tiles 
that currently exist in our version of the TileDesigner file. 
I run the XML exported by TileDesigner through a utility that 
extracts the connectivity information from it*.

>From this big file, another utility extracts the tiles needed 
for a particular game into a game-specific subset Tiles.xml file.

As it is now, we have to live which the original TileDesigner
features. This does not cover all our graphics needs 
(for instance, we can't create off-board tiles with "arrows"), 
but for creating the connectivity XML in a simple way 
it seems good enough to me.

I'll look at your upload later.

For now it seems to me, that I can best continue to create new
tiles via TileDesigner for the purpose of XML creation,
whereas Brett can meanwhile work with you to see if we can obtain
better graphics that way.

Any remaining numbering or naming differences can be resolved via our 
manually coded TileSet.xml files, e.g. by the 'pic' attribute
that I proposed in an earlier post.

Erik.

*which is why I prefer the old-style 80-83 tiles for this purpose.

Re: [Rails-devel] 18EU Tile number overlaps

[John A. T. <ja...@ja...>]

On Thu, 25 Oct 2007, Erik Vos wrote:

> I haven't seen yet what you have sent, John.
> Was it a complete tile set for all games that you have covered,
> or a subset for 18EU?

I posted it here a couple of weeks ago -- I think it was just the EU 
special tiles.

> We should somehow agree on a common numbering and XML format.
> The overall tiles/Tiles.xml has been created from Marco's TileDesigner file,
> extended by me, by a conversion utility.

I am not sure there are common interests.  I took the TileDesigner format 
and extended it for my needs, and then I have a database schema where the 
authoritive data is kept which also has a lot more detail about rendering. 
Initially the detailed layout data was automatically generated from 
code derived from TileDesigner, then I could manually tweak it if needed 
(and there is a flag saying if it was automatically generated so it can be 
regenerated if I improve the layout code).

Since Rails doesn't render the tiles from the tile data, it seems like 
most of that data is useless to Rails.  Also, I currently do not keep 
information useful for route calculations which Rails will eventually 
need, although I wouldn't be averse to extended it and storing it as well. 
Finally, I am more concerned with a unified database of all tiles so I can 
search for which games contain which tiles etc while Rails doesn't care 
for such a database (at least that is my recollection of a discussion 
about this a couple of years ago).

XML is not a particularly good format for storing the data, but it is good 
for information interchange.  I would be willing to write import/export 
code from my database to some common XML format if it seems useful.  I 
have extended TileDesigner data for every game I produce and most of the 
others (and I imported connectivity data from ps18xx tiles, but many of 
them have poor layout data).

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] 18EU Tile number overlaps

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

> In the data I sent, code is the unique id and number is the value to 
> displayed on the tile if different from code.

I haven't seen yet what you have sent, John.
Was it a complete tile set for all games that you have covered,
or a subset for 18EU?

We should somehow agree on a common numbering and XML format.
The overall tiles/Tiles.xml has been created from Marco's TileDesigner file,
extended by me, by a conversion utility.

Erik.

Re: [Rails-devel] 18EU Tile number overlaps

[John A. T. <ja...@ja...>]

On Thu, 25 Oct 2007, Erik Vos wrote:

> 18EU tiles 80-83 look different from those in older games,
> but aren't with respect to what connections exist.
> And for route determination (in the future) we will need the edge-to-edge
> connections, as specified in the XML tile spec of the 'classical' format
> (i.e. the existing tiles 80-83).

Actually that doesn't matter, as you already have to be able to trace 
connectivity through junctions.

> A simple solution would be to keep using the existing tile pictures.
> If you (understandably) would like to use the new 18EU format,
> one solution would be to give these pictures a high number
> (like 5080 etc), but otherwise use the existing low-numbered
> specs.
>
> The XML in 18EU/TileSet.xml for these tiles could then be like
> 	<Tile id="80" pic="5080" quantity="4">
> 		<Upgrade id="545,546" />
> 	</Tile>
>
> The Tile spec in Tiles.xml should stay like
> 	<Tile colour="green" id="80" name="80">
> 		<Track from="side1" gauge="normal" to="side2"/>
> 		<Track from="side1" gauge="normal" to="side3"/>
> 		<Track from="side2" gauge="normal" to="side3"/>
> 	</Tile>
> or similar. The new-style XML spec for 5080 would not be used.
>
> Similar considerations apply to 544-546, although we don't have
> a 'classical' format there. But we need at least an XML version
> of it on behalf of Tiles.xml.

There the connectivity actually is different.

> On tiles -5 through -11:
> I think -10 and perhaps -11 already existed in Marco's
> original TileDesigner, has John changed these?
> -5 through -9 are free as far as I am concerned.

I corrected orientations on a number of them

> On duplicate numbers for really different tiles:
> here indeed we should use internal and external numbers.
>
> The current attribute "id" is intended to be unique internal number.
> If the external number (shown in the UI etc.) is different,
> we need an additional attribute for that purpose.

In the data I sent, code is the unique id and number is the value to 
displayed on the tile if different from code.

> On different "base" rotations: we'll need an extra attribute
> in TileSet.xml for that purpose, for instance (just a random example):
> 	<Tile id="26" rotation="2" quantity="2">
> 		<Upgrade id="42,44,45" />
> 	</Tile>
> All reported rotations (inclusing those in Map.xml)
> would be relative to this base rotation.

Yes, that is what I do (except the map rotation is relative to the tile 
manifest rotation).

> I agree with the posters who maintain that we should remain
> consistent with the tiles as they exist in each game.
> Even then we face problems: in 1830, tile #45 exists in two
> different base rotations! How do PBEMmers solve that problem?

I remember Steve Thomas had a solution for that, but I don't remember what 
it was.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] 18EU Tile number overlaps

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

Revisiting

> The Tile spec in Tiles.xml should stay like
> 	<Tile colour="green" id="80" name="80">
> 		<Track from="side1" gauge="normal" to="side2"/>
> 		<Track from="side1" gauge="normal" to="side3"/>
> 		<Track from="side2" gauge="normal" to="side3"/>
> 	</Tile>
> or similar. The new-style XML spec for 5080 would not be used.

and
 
> On duplicate numbers for really different tiles: 
> here indeed we should use internal and external numbers.
> 
> The current attribute "id" is intended to be unique internal number.
> If the external number (shown in the UI etc.) is different,
> we need an additional attribute for that purpose.

I can add, that in fact we already have the 'name' attribute 
containg the external numbers 
(except for preprinted tiles numbered < 0, but those don't matter).

See for instance in the generic tiles/Tiles.xml:

	<Tile colour="green" id="12" name="12">
		<Station id="city1" position="0" slots="1" type="City"
value="30"/>
		<Track from="city1" gauge="normal" to="side1"/>
		<Track from="city1" gauge="normal" to="side2"/>
		<Track from="city1" gauge="normal" to="side3"/>
	</Tile>
	<Tile colour="green" id="1012" name="12">
		<Station id="city1" position="0" slots="2" type="City"
value="50"/>
		<Track from="city1" gauge="normal" to="side1"/>
		<Track from="city1" gauge="normal" to="side2"/>
		<Track from="city1" gauge="normal" to="side3"/>
	</Tile>

So we're fine on that aspect.

Erik.

Re: [Rails-devel] 18EU Tile number overlaps

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

18EU tiles 80-83 look different from those in older games, 
but aren't with respect to what connections exist.
And for route determination (in the future) we will need the edge-to-edge
connections, as specified in the XML tile spec of the 'classical' format
(i.e. the existing tiles 80-83).

A simple solution would be to keep using the existing tile pictures.
If you (understandably) would like to use the new 18EU format, 
one solution would be to give these pictures a high number 
(like 5080 etc), but otherwise use the existing low-numbered
specs.

The XML in 18EU/TileSet.xml for these tiles could then be like
	<Tile id="80" pic="5080" quantity="4">
		<Upgrade id="545,546" />
	</Tile>

The Tile spec in Tiles.xml should stay like
	<Tile colour="green" id="80" name="80">
		<Track from="side1" gauge="normal" to="side2"/>
		<Track from="side1" gauge="normal" to="side3"/>
		<Track from="side2" gauge="normal" to="side3"/>
	</Tile>
or similar. The new-style XML spec for 5080 would not be used.

Similar considerations apply to 544-546, although we don't have
a 'classical' format there. But we need at least an XML version
of it on behalf of Tiles.xml.

----------

On tiles -5 through -11: 
I think -10 and perhaps -11 already existed in Marco's
original TileDesigner, has John changed these? 
-5 through -9 are free as far as I am concerned.	

----------

On duplicate numbers for really different tiles: 
here indeed we should use internal and external numbers.

The current attribute "id" is intended to be unique internal number.
If the external number (shown in the UI etc.) is different,
we need an additional attribute for that purpose.

----------

On different "base" rotations: we'll need an extra attribute
in TileSet.xml for that purpose, for instance (just a random example):
	<Tile id="26" rotation="2" quantity="2">
		<Upgrade id="42,44,45" />
	</Tile>
All reported rotations (inclusing those in Map.xml) 
would be relative to this base rotation.

I agree with the posters who maintain that we should remain
consistent with the tiles as they exist in each game.
Even then we face problems: in 1830, tile #45 exists in two
different base rotations! How do PBEMmers solve that problem?


Erik.


> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf 
> Of Brett Lentz
> Sent: Thursday 25 October 2007 00:03
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] 18EU Tile number overlaps
> 
> I'm working on importing the new tiles for 18EU, but I've run 
> into some
> overlaps in tile numbering.
> 
> I was able to import the TileDesigner data from John. Unfortunately,
> these tiles already exist (and are different tiles): -5, -6, 
> -7, -8, -9,
> -10, -11, 80, 81, 82, 83.
> 
> So, it looks like I'll need to re-number these 18EU tiles. Any
> suggestions on what the new tile numbers ought to be?
> 
> 
>  ---Brett.
> 
> 
> 	"Fantasies are free."
> 	"NO!! NO!! It's the thought police!!!!"
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and 
> a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 

Re: [Rails-devel] 18EU Tile number overlaps

[Brett L. <wak...@gm...>]

On Thu, 2007-10-25 at 13:05 -0400, John A. Tamplin wrote:
> On Thu, 25 Oct 2007, brett lentz wrote:
> 
> > If there's someone who wants to dedicate some effort to working on the
> > tile images, then it will happen a lot faster.
> 
> What exactly do you need?  I can generate EPS and PNG directly from the 
> tile database for arbitrary games.  SVG would be a bit more work, but 
> perhaps my tile data could be loaded into TileDesigner with less effort, 
> and I believe it generates reasonable SVG.
> 

Unfortunately TileDesigner does not generate usable SVG. I'm not sure if
the problem is TileDesigner or the Batik library, but I've already gone
down that path.

The way I've been obtaining SVGs is to export to PS from TileDesigner,
then use pstoedit to convert them to SVG. From there, each tile needs a
bit of tweaking that I have been doing with Inkscape, but should be
scriptable without too much trouble.

So, ideally, what I need is GIFs and SVGs of each tile.  Or, if that
won't work for you, I'd also accept a more complete TileDesigner
database.


 ---Brett.


  Our comedies are not to be laughed at. -Samuel Goldwyn

Re: [Rails-devel] 18EU Tile number overlaps

[John A. T. <ja...@ja...>]

On Thu, 25 Oct 2007, brett lentz wrote:

> If there's someone who wants to dedicate some effort to working on the
> tile images, then it will happen a lot faster.

What exactly do you need?  I can generate EPS and PNG directly from the 
tile database for arbitrary games.  SVG would be a bit more work, but 
perhaps my tile data could be loaded into TileDesigner with less effort, 
and I believe it generates reasonable SVG.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] 18EU Tile number overlaps

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

On 10/25/07, John A. Tamplin <ja...@ja...> wrote:
> On Thu, 25 Oct 2007, brett lentz wrote:
>
> > It's not a real issue. As I already said, we don't (and won't) change
> > the tile number printed on the tile graphic.
> >
> > However, this information is helpful in preventing the exact thing you
> > described: developers not knowing how their software is being used and
> > not incorporating that information into their design goals.
>
> So, just to make sure I understand your position, are you saying it is or
> is not a design goal to be able to use Rails with physical copies of the
> games to play by mail/email?  That is really the entire point of the tile
> numbers themselves, so I would suggest that if you do not agree that
> should be a goal there is no point putting the tile numbers on there at
> all.
>


It's not a primary concern. I'd call it a low priority design goal.
If we can do it easily without adding a lot of extra overhead, we'll
try to fit it in.

If there's someone who wants to dedicate some effort to working on the
tile images, then it will happen a lot faster.


---Brett

Re: [Rails-devel] 18EU Tile number overlaps

[John A. T. <ja...@ja...>]

On Thu, 25 Oct 2007, brett lentz wrote:

> It's not a real issue. As I already said, we don't (and won't) change
> the tile number printed on the tile graphic.
>
> However, this information is helpful in preventing the exact thing you
> described: developers not knowing how their software is being used and
> not incorporating that information into their design goals.

So, just to make sure I understand your position, are you saying it is or 
is not a design goal to be able to use Rails with physical copies of the 
games to play by mail/email?  That is really the entire point of the tile 
numbers themselves, so I would suggest that if you do not agree that 
should be a goal there is no point putting the tile numbers on there at 
all.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] 18EU Tile number overlaps

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

On 10/25/07, Chris Shaffer <chr...@gm...> wrote:
> > Hmm...  I think there's the exact disconnect.
> >
> > You see, with an implementation like Rails, that eliminates the causes
> > for much of those problems.   Rather than trying to figure out what
> > version of the printed game each player has, you all centralize on the
> > same computer version, which handles all of those details for you.
> > This allows you to just focus on the printed image rather than trying
> > to get verbal descriptions correct.
>
> Yup, that's the disconnect.  You'd think people would centralize on
> the computer version, but that's definitely not always going to be the
> case, and it assumes a lot about people's behavior.  In my experience,
> we use Cyberboard and Vassal gameboxes in many ways that are
> unanticipated by the module/program designers.
>
> One scenario: there have been a number of times that we've played a
> partial game at the game store, which closes at 10pm.  We then write
> down as much as we can, take a couple of snapshots of the board, and
> close up for the night.  Later, I convert all of that to Cyberboard
> and a spreadsheet.  We play some of the game by email, some of us
> using Cyberboard, some of us simply relying on the notes, photos and
> an occasional screenshot sent by the others.  Then, a while later, one
> of us sets up the game at the game shop and we finish it out.
>
> Another scenario: we're all using Vassal to play 18AL via direct
> connect.  Partway through the game, we wrap it up and convert to play
> by email.  One guy can't run programs at work, but still takes turns,
> relying on printouts and his physical copy of the rules and charts -
> including the tile upgrade charts.  If he had to wait until he could
> run the program, it would slow down the pbem portion of the game quite
> a bit.
>
> That's a long way of saying you're not making new games, you're
> converting old ones -- and imho, it's worth the time and effort to be
> as consistent as possible with the printed copies of the games.
> Introducing any variance is a way of introducing the possibility of
> rules arguments - something to be avoided.
>
> I don't see why this is a real issue, actually.  John pointed out the
> easy solution.  Simply use an internal ID system.
>


It's not a real issue. As I already said, we don't (and won't) change
the tile number printed on the tile graphic.

However, this information is helpful in preventing the exact thing you
described: developers not knowing how their software is being used and
not incorporating that information into their design goals.


---Brett.

Re: [Rails-devel] 18EU Tile number overlaps

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

> Hmm...  I think there's the exact disconnect.
>
> You see, with an implementation like Rails, that eliminates the causes
> for much of those problems.   Rather than trying to figure out what
> version of the printed game each player has, you all centralize on the
> same computer version, which handles all of those details for you.
> This allows you to just focus on the printed image rather than trying
> to get verbal descriptions correct.

Yup, that's the disconnect.  You'd think people would centralize on
the computer version, but that's definitely not always going to be the
case, and it assumes a lot about people's behavior.  In my experience,
we use Cyberboard and Vassal gameboxes in many ways that are
unanticipated by the module/program designers.

One scenario: there have been a number of times that we've played a
partial game at the game store, which closes at 10pm.  We then write
down as much as we can, take a couple of snapshots of the board, and
close up for the night.  Later, I convert all of that to Cyberboard
and a spreadsheet.  We play some of the game by email, some of us
using Cyberboard, some of us simply relying on the notes, photos and
an occasional screenshot sent by the others.  Then, a while later, one
of us sets up the game at the game shop and we finish it out.

Another scenario: we're all using Vassal to play 18AL via direct
connect.  Partway through the game, we wrap it up and convert to play
by email.  One guy can't run programs at work, but still takes turns,
relying on printouts and his physical copy of the rules and charts -
including the tile upgrade charts.  If he had to wait until he could
run the program, it would slow down the pbem portion of the game quite
a bit.

That's a long way of saying you're not making new games, you're
converting old ones -- and imho, it's worth the time and effort to be
as consistent as possible with the printed copies of the games.
Introducing any variance is a way of introducing the possibility of
rules arguments - something to be avoided.

I don't see why this is a real issue, actually.  John pointed out the
easy solution.  Simply use an internal ID system.

-- 
Chris

Keep the flying car. I want the future where "resurrection" is a
medical specialty.

Re: [Rails-devel] 18EU Tile number overlaps

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

On 10/24/07, Chris Shaffer <chr...@gm...> wrote:
> > Hmm...  either I don't understand your description, or I have a
> > completely different design goal, but that sounds way more complex
> > than it really needs to be to implement a playable game.  Having
> > multiple tiles that are the same ID but different rotations doesn't
> > make sense to me. Why wouldn't you have one tile, know the starting
> > rotation, then calculate the other rotations?
>
> Because the orientation/location of the printed number on the tile is
> what is used by players in play-by-email to describe the position of
> the tile.  You have to account for all the possibilities in playing
> the game.
>
> I'm currently in a play-by-email game with someone who can charitably
> be described as computer-illiterate.  Over the course of the game,
> we've had to reset his turn and rebuild the spreadsheet several times.
>  If we didn't have a consistent way to describe tile orientations
> (within that particular game, compared to the actual physical copy of
> the game that he owns and has set up in his basement), we wouldn't be
> able to play.  Despite the challenges of playing with this fellow, I'm
> really enjoying the game, and he's a good player.  He just has no clue
> how the computer really works.
>
> Thus, it's important to mimic the printed games as closely as
> possible, as John Tamplin described.
>


Hmm...  I think there's the exact disconnect.

You see, with an implementation like Rails, that eliminates the causes
for much of those problems.   Rather than trying to figure out what
version of the printed game each player has, you all centralize on the
same computer version, which handles all of those details for you.
This allows you to just focus on the printed image rather than trying
to get verbal descriptions correct.


---Brett.

Re: [Rails-devel] 18EU Tile number overlaps

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

> Hmm...  either I don't understand your description, or I have a
> completely different design goal, but that sounds way more complex
> than it really needs to be to implement a playable game.  Having
> multiple tiles that are the same ID but different rotations doesn't
> make sense to me. Why wouldn't you have one tile, know the starting
> rotation, then calculate the other rotations?

Because the orientation/location of the printed number on the tile is
what is used by players in play-by-email to describe the position of
the tile.  You have to account for all the possibilities in playing
the game.

I'm currently in a play-by-email game with someone who can charitably
be described as computer-illiterate.  Over the course of the game,
we've had to reset his turn and rebuild the spreadsheet several times.
 If we didn't have a consistent way to describe tile orientations
(within that particular game, compared to the actual physical copy of
the game that he owns and has set up in his basement), we wouldn't be
able to play.  Despite the challenges of playing with this fellow, I'm
really enjoying the game, and he's a good player.  He just has no clue
how the computer really works.

Thus, it's important to mimic the printed games as closely as
possible, as John Tamplin described.

-- 
Chris

Keep the flying car. I want the future where "resurrection" is a
medical specialty.

Re: [Rails-devel] 18EU Tile number overlaps

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

On 10/24/07, John A. Tamplin <ja...@ja...> wrote:
> brett lentz wrote:
> > That was really the crux of the original question.  The tile number
> > printed on the image itself remains unchanged.  Unfortunately, modern
> > filesystems don't allow me to have two versions of "tile80.svg", so I
> > need to pick one of the overlapping images and call it something else.
> >
> Then use the unique ID in the filename -- it can be anything you like.
> Note that the code field in the TileDesigner data is insufficient as
> there are still duplicates across different games and there are
> different orientations for the same tile number (sometimes even within
> the same game!).  My solution to the latter problem is to have a tile
> id, rotation, and count in the tile manifest table for a game, so there
> can be multiple rotations of the same tile in one game.
>

Hmm...  either I don't understand your description, or I have a
completely different design goal, but that sounds way more complex
than it really needs to be to implement a playable game.  Having
multiple tiles that are the same ID but different rotations doesn't
make sense to me. Why wouldn't you have one tile, know the starting
rotation, then calculate the other rotations?

> A related problem is that some games have had different tile mixes over
> the years, such as some 1825/1829 sets (and maybe 1853).  My solution
> for those is to treat them as different games which happen to have the
> same name.

My plan is similar to how we've handled variants like 1830's optional
6 train: construct the game engine API to allow the UI to manipulate
these values prior to game startup.


---Brett

Re: [Rails-devel] 18EU Tile number overlaps

[John A. T. <ja...@ja...>]

brett lentz wrote:
> That was really the crux of the original question.  The tile number
> printed on the image itself remains unchanged.  Unfortunately, modern
> filesystems don't allow me to have two versions of "tile80.svg", so I
> need to pick one of the overlapping images and call it something else.
>   
Then use the unique ID in the filename -- it can be anything you like.  
Note that the code field in the TileDesigner data is insufficient as 
there are still duplicates across different games and there are 
different orientations for the same tile number (sometimes even within 
the same game!).  My solution to the latter problem is to have a tile 
id, rotation, and count in the tile manifest table for a game, so there 
can be multiple rotations of the same tile in one game.

A related problem is that some games have had different tile mixes over 
the years, such as some 1825/1829 sets (and maybe 1853).  My solution 
for those is to treat them as different games which happen to have the 
same name.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

Re: [Rails-devel] 18EU Tile number overlaps

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

On 10/24/07, Chris Shaffer <chr...@gm...> wrote:
> > I'm not suggesting using different tile numbers -- I am saying to
> > distinguish game X's tile A from game Y's tile A each tile would have a
> > unique tile id, which is not printed on the tile, while the tile number
> > attribute would be A in each case.
>
> Definitely agree on this - the display should match the documentation
> and printed game.  A unique ID that isn't displayed will do fine, as
> you suggested earlier.
>

That was really the crux of the original question.  The tile number
printed on the image itself remains unchanged.  Unfortunately, modern
filesystems don't allow me to have two versions of "tile80.svg", so I
need to pick one of the overlapping images and call it something else.


---Brett.