From: Oliver H. <oli...@ok...> - 2011-02-16 19:40:07
|
Hi, are there any plans implementing 1853? Cheers, Oliver |
From: Justin R. <jus...@gm...> - 2011-02-16 20:27:28
|
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 > |
From: brett l. <bre...@gm...> - 2011-02-16 21:20:28
|
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 > |
From: Oliver H. <oli...@ok...> - 2011-02-16 22:14:42
|
Brett, thanks for your comprehensive explanations. Sounds interesting, I think I will give it a try. Must see, how much time this takes. And I am not really into programming. From my perspective it would be nice to have the stock market implemented first, as this would really help to speed up face-to-face games. But I would expect quite a lot of extra rules and changes in 1953 as the concept of narrow gauge is unique. Cheers, Oliver Am 16.02.2011 22:19, schrieb brett lentz: > 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. |
From: Stefan F. <jk...@gm...> - 2011-02-17 04:01:46
|
Hello Brett, Am 16.02.2011 22:19, schrieb brett lentz: > 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. Even if I am not sure if I can help, I went to the sourceforge site and searched for the informations that you just gave, but couldn't find them. Your email should not end buried in the mailinglist archives, as many other informations, but on the rails wiki. I just tried to do, after setting up an account, but the pages are protected. ciao stefan |
From: Russell A. <ra...@mt...> - 2011-02-16 23:27:50
|
Hi there, Is it possible to create a Rails save file that represents a game part way through? For instance, we're playing a game of 18AL "live" and need to save the game. We could finish it off using Rails, but rebuilding the game from scratch will be impossible. Is there any way of entering a game into a save file that represents a current position? R. |
From: Chris S. <chr...@gm...> - 2011-02-16 23:52:28
|
I'd think you could use "correction mode" to do this. It wouldn't be trivial, but it would certainly be easier than recreating the game by playing from SR1 forward. -- Chris Please consider the environment before printing this e-mail. On Wed, Feb 16, 2011 at 3:14 PM, Russell Alphey <ra...@mt...> wrote: > Hi there, > Is it possible to create a Rails save file that represents a game part > way through? > > For instance, we're playing a game of 18AL "live" and need to save the > game. We could finish it off using Rails, but rebuilding the game from > scratch will be impossible. Is there any way of entering a game into a save > file that represents a current position? > > R. > > > > ------------------------------------------------------------------------------ > 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 > > |