Re: [Rails-devel] Support Needed: New complex Tiles and Maps

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

John:
Thanks for your recommendations. Some quick comments below.
Your comments are always helpful, so feel free to share your thoughts.
Stefan

> I wouldn't have kept the .18t file format with its painful conventions
> for one.

Yes that will be replaced by Tiles.xml, which is much nicer to write.

>
> For another, I would have separated tile layout from tile drawing, and
> supported the tile definition either using the high-level approach of
> "the city is here, and it is connected to these locations" and letting
> the layout be generated, or allow you to specify the layout (exact
> positions, rotations, etc) - as it, especially on crowded tiles, I had
> to do special-case layout things and it still isn't great.  I would have
> also generalized the track layout to build bezier curves directly rather
> than keeping all the special-case code for "if this position is
> connected to this position, draw it this way".

Most likely I will follow your recommendation to separate track 
configuration from tile drawing hints (where to position stations etc.).

I even consider making another step: Allow parametrized tiles, tiles 
that use the same track layout, but differ in the station values and 
labels: Currently a new tile is defined any time the station value 
changes and/or a label is added to the tile.

One could even consider the tile color to be a parameter of the tile and 
thus there is no need to duplicate the track layout definition only 
because the color changes.

For sure they are different tiles that are required for a physical game, 
but not if they get generated automatically.

One thing that we still want to support is a (visible to the user) 
tile-id that is identical to the 18xx tiles database and used for the 
boardgame.

>
>     And: You are right, writing to Swing is an option.
>     However I expect that any suitable Java svg libraries with support for
>     Swing allow the creation of a svg file by writing to a Graphics2D
>     object. So if java as the implementation language switching from svg to
>     direct painting will be nearly transparent.
>
>
> Let's just say I am skeptical of using an API designed for drawing on
> the screen and getting good results generating SVG from it, but feel
> free to go that route if you prefer.
>
> --

I agree with your sentiment. It seems odd to first create SVG via a 
Swing API dynamically and then convert the SVG back into Swing graphics.
But this might be true only for the time being. Later on Rails graphics 
might be produced by another GUI library than Swing and/or the graphic 
shown is generated by a different SVG library, that uses a different API 
for creation. And given the current situtation I do not want to be tied 
to Swing.

However all existing Java svg libraries create SVG files from Java via 
the Swing Graphics API. I wonder how this is solved by other languages. 
Is doubt that operating on the SVG via XML DOM is preferable.
I would prefer an API similar to the javascript library 
http://raphaeljs.com/ .

Given the fact that Java 6 ships JS support via the Rhino engine, and 
Java 8 comes with a brand-new JS engine (Nashorn), most likely raphaeljs 
is the way to go.