Re: [Rails-users] Adding new games

[Aliza P. <ali...@gm...>]

More than once I've thought about learning Java so that I can help
implement 18C2C in Rails. :-)

Interesting features:
Two privates with early buy-ins allowed
Private buy-in enabled after a stock round after the first 3-train bought
A private power that restricts only the orientation of tiles on the
(many) hexes it blocks
Share redemption (company swallows a share) and reissuing
Share privatization (like 1835 -- pay a steadily increasing premium to
yank a share from another player)
Pairwise mergers
  Train shuffles in merged corporations
Nationalization of trainless companies into two government conglomerates
"Bull" tokens which can be placed in full cities
Destination tokens and runs
"Golden Spike" one-time stock bumps for runs that include cities in
Set A and Set B
In the "D" version, "D" trains which calculate their runs differently
A huge map that might stress the Rails database and UI
32 companies (plus two public mergers) which will make the interface challenging

Wow, that's a lot of stuff.  :-)

(Note: I have a few decades of programming experience, none of which
happens to be in Java.  These days, though, I do a bit of scripting in
shell and Perl, and a lot of reading other people's C code.)

On Wed, Feb 16, 2011 at 1:19 PM, brett lentz <bre...@gm...> wrote:
> Oliver -
>
> At a high level, there is interest in adding all 18xx games to Rails.
> However, in the more near term, we have not yet had much discussion
> about 1853. What the next supported game is going to be is currently
> an open question.
>
> I'll provide a bit more detail on the process for adding a new game.
> This should help with understanding what it takes to add a new game.
>
> We rely very heavily on the time and interest of volunteers. So, as
> you can imagine, the choice of which games to implement next depends a
> lot on someone stepping up to do the work. We're always looking for
> more people who are interested in helping improve Rails in both big
> and small ways.
>
> Adding a new game can be broken up into a few pieces, some of which
> don't require much programming experience.
>
> 1. Create Game-specific XML files. The map, tileset, and other XML
> files define what components make up the game and what special or
> optional rules are available. These are created mostly by hand, and
> only require some familiarity with markup languages, but don't
> particularly require programming experience.
>
> 2. Create any new Tile graphics. This isn't always required. We have a
> pretty good library of tile graphics already created, but occasionally
> a game will add some new tiles that we don't have. This requires the
> use of Marco Rocci's Tile Designer and a few post-processing steps,
> but no real programming experience is needed.
>
> 3. Identify rules differences and specialty rules that aren't yet
> implemented. Here's where the bulk of the programming work begins. If
> the game uses rules that are from games that we have already
> implemented, the programming effort is usually pretty minimal (e.g.
> 18Kaas is 1830 on a different map. Adding support for it only required
> the game XML and little else). Depending on the size of this work,
> adding support for 1853 may be trivial, or it might be several hours
> of work, which is likely to be spread over several weeks or months
> depending on how much time someone has available to dedicate to the
> effort.
>
> 4. Integration with other features.  Now that we have support for
> route calculation and other features, there may be additional work
> required to support those features within the new game.
>
>
> ---Brett.
>
>
>
> On Wed, Feb 16, 2011 at 12:27 PM, Justin Rebelo <jus...@gm...> wrote:
>> You're our first volunteer!
>>
>> On Wed, Feb 16, 2011 at 11:21 AM, Oliver Heck <oli...@ok...> wrote:
>>> Hi,
>>>
>>> are there any plans implementing 1853?
>>>
>>> Cheers,
>>> Oliver
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
>>> Pinpoint memory and threading errors before they happen.
>>> Find and fix more than 250 security defects in the development cycle.
>>> Locate bottlenecks in serial and parallel code that limit performance.
>>> http://p.sf.net/sfu/intel-dev2devfeb
>>> _______________________________________________
>>> Rails-users mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-users
>>>
>>
>> ------------------------------------------------------------------------------
>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
>> Pinpoint memory and threading errors before they happen.
>> Find and fix more than 250 security defects in the development cycle.
>> Locate bottlenecks in serial and parallel code that limit performance.
>> http://p.sf.net/sfu/intel-dev2devfeb
>> _______________________________________________
>> Rails-users mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-users
>>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Rails-users mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-users
>