Menu
▾
▴
rails-devel
|
From: Jonathan F. <jon...@ya...> - 2008-09-18 15:05:49
|
Several years ago I posted an idea for an algorithm based on computing half-routes (starting from stations an only going one direction) but I've never proved to myself that the filtering needed (to combine them into full routes and not conflict with other trains in a corp) would be practical. I think that was the last time it was openly discussed, and I've never looked into the code to see how that would fit with the current game-state internals. -- Jonathan ----- Original Message ---- From: brett lentz <wak...@gm...> To: Development list for Rails: an 18xx game <rai...@li...> Sent: Thursday, September 18, 2008 8:10:11 AM Subject: Re: [Rails-devel] track/route awareness On Thu, Sep 18, 2008 at 2:49 AM, Michał Bażyński <ba...@tl...> wrote: > hello, > is anybody working on things like recognizing legal track builds or > calculating revenue? not that I am ready to announce I intend to do it, > but if it's a work in progress already it won't make sense for me to > look into that problem at all... > > mike bazynski Nobody has stepped forward to work on route awareness. We have a basic implementation for matching legal plays by tracking which sides of each hex have track, and lining them up to the sides of each other hex that has track. If you would like to work on route calculation, you're welcome to it. ---Brett. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Mark S. <mar...@gm...> - 2008-09-18 17:09:56
|
Back many years ago early 90's I started a personal project to implement the 18xx game system on my computer, using C++. When JAVA came out, I translated what I had done to JAVA and then put it away for a decade. When I found your SourceForge project back late 2006 I brought it back out and made progress. My initial focus, and still to be fully complete to my satisfaction is drawing and manipulating the board, tiles, track, stations, etc. My feeling is that the board is central to the entire game system, and if not done properly, you can't really play the game properly. I have reviewed what your Rails project does with the board, and the fact that you make use of GIF images for the tiles, tokens, etc. I see at least two distinct issues with your current implemenation, one is the tokens are just a circle of a specific color. If you look at 1835, or 1837 there are minor companies that share the SAME color, so that it is very hard to tell from your map which minor company starts where. The other issue as I know from your forum has not yet been solved is scaling the map up and down in size. My approach was to use the track connections, station locations, types, and stuff to draw the board and tiles via Vector Graphics. This gives me not only a very clean drawing, but one that can scale up and down in size with little extra coding efforts. The tokens I draw are filled circles with the company Abbreviation/Number centered in the token. I also draw my default size larger, about the same size as the tiles if you hold them up to the screen. One other advantage is that since I draw the track segment by segment, I can draw routes for different trains in different colors, so that you can tell at a glance if they conflict, and the program will know if they would re-use track and say "NAY, no re-use buddy!". But I have not gotten it to that specific point yet. but I am close to actually implementing a way to have the user pick out the routes. Now this last point brings up a philosphical question of game implementation. Should the Player pick the routes, or should the computer auto-calculate the routes to maximize income? The game rules specifically state the player picks routes, and has to live with the mistake. However, sometimes in some games (like 1853), you may want to maximize your mail run, or maximize your revenue at different times. If there is intrest, I could be enticed to provide a copy of a JAVA JAR File that could be run to see if my approach sparks interest. I feel that it might be worth considering a possible integration of my map/tile routines into Rails... but only the current product looks promising to those currently implementing. Let me know what you all think. Mark Smith On Thu, Sep 18, 2008 at 5:05 PM, Jonathan Ferro <jon...@ya...>wrote: > Several years ago I posted an idea for an algorithm based on computing > half-routes (starting from stations an only going one direction) but I've > never proved to myself that the filtering needed (to combine them into full > routes and not conflict with other trains in a corp) would be practical. I > think that was the last time it was openly discussed, and I've never looked > into the code to see how that would fit with the current game-state > internals. > > -- Jonathan > > > > ----- Original Message ---- > From: brett lentz <wak...@gm...> > To: Development list for Rails: an 18xx game < > rai...@li...> > Sent: Thursday, September 18, 2008 8:10:11 AM > Subject: Re: [Rails-devel] track/route awareness > > On Thu, Sep 18, 2008 at 2:49 AM, Michał Bażyński <ba...@tl...> wrote: > > hello, > > is anybody working on things like recognizing legal track builds or > > calculating revenue? not that I am ready to announce I intend to do it, > > but if it's a work in progress already it won't make sense for me to > > look into that problem at all... > > > > mike bazynski > > > Nobody has stepped forward to work on route awareness. We have a > basic implementation for matching legal plays by tracking which sides > of each hex have track, and lining them up to the sides of each other > hex that has track. > > If you would like to work on route calculation, you're welcome to it. > > ---Brett. > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Michał B. <ba...@tl...> - 2008-09-19 00:31:47
|
I intend to try the brute-force approach and see why it fails :-) for single trains brute-force should be more than enough, and you don't see more than 2 big trains in one company at the same time, do you? the other idea is that I know the lead programmer of 1830 computer game, I'll ask how he solved this problem (the PC game is extremely quick in calculating this)... Mark Smith wrote: > Now this last point brings up a philosphical question of game > implementation. Should the Player pick the routes, or should the > computer auto-calculate the routes to maximize income? The game rules > specifically state the player picks routes, and has to live with the > mistake. However, sometimes in some games (like 1853), you may want to > maximize your mail run, or maximize your revenue at different times. the 1830pc game calculates it for you, and I would be more than willing to sacrifice the player not losing when he doesn't see a best route for the huge time gain this would bring. a player could still run the train for a shorther route if none of the shareholders objected... best regards, mike bazynski |
|
From: Erik V. <eri...@hc...> - 2008-09-19 02:09:49
|
I have reviewed what your Rails project does with the board, and the fact that you make use of GIF images for the tiles, tokens, etc. I see at least two distinct issues with your current implemenation, one is the tokens are just a circle of a specific color. If you look at 1835, or 1837 there are minor companies that share the SAME color, so that it is very hard to tell from your map which minor company starts where. The latest version does draw company abbreviations on top of each token. Not in vector graphics, though, so it probably won't scale. Erik. |
|
From: Brett L. <wak...@gm...> - 2008-09-18 17:49:45
|
On Thu, 2008-09-18 at 19:09 -0500, Mark Smith wrote: > I have reviewed what your Rails project does with the board, and the > fact that you make use of GIF images for the tiles, tokens, etc. I see > at least two distinct issues with your current implemenation, one is > the tokens are just a circle of a specific color. If you look at 1835, > or 1837 there are minor companies that share the SAME color, so that > it is very hard to tell from your map which minor company starts > where. The other issue as I know from your forum has not yet been > solved is scaling the map up and down in size. > > My approach was to use the track connections, station locations, > types, and stuff to draw the board and tiles via Vector Graphics. This > gives me not only a very clean drawing, but one that can scale up and > down in size with little extra coding efforts. Looks like you missed the SVG tiles we have. We're using Batik to handle the rendering of SVG tiles. Much of the drawing code is fairly basic and there are several known issues that make me want to try rewriting large sections of it. However, you're welcome to take on that task. It sounds like we've got a lot of similar ideas on how it should be done. :-) > The tokens I draw are filled circles with the company > Abbreviation/Number centered in the token. I also draw my default size > larger, about the same size as the tiles if you hold them up to the > screen. One other advantage is that since I draw the track segment by > segment, I can draw routes for different trains in different colors, > so that you can tell at a glance if they conflict, and the program > will know if they would re-use track and say "NAY, no re-use buddy!". > But I have not gotten it to that specific point yet. but I am close to > actually implementing a way to have the user pick out the routes. > Interesting. Perhaps you'd like to work on merging codebases? > Now this last point brings up a philosphical question of game > implementation. Should the Player pick the routes, or should the > computer auto-calculate the routes to maximize income? The game rules > specifically state the player picks routes, and has to live with the > mistake. However, sometimes in some games (like 1853), you may want to > maximize your mail run, or maximize your revenue at different times. > I would prefer to support both options, and leave it up to the user to select an option at runtime. > If there is intrest, I could be enticed to provide a copy of a JAVA > JAR File that could be run to see if my approach sparks interest. I > feel that it might be worth considering a possible integration of my > map/tile routines into Rails... but only the current product looks > promising to those currently implementing. > There's definitely interest. We can always use more people contributing code. :-) In general, if you're contributing code, I (usually) leave the implementation details up to you. Unless there's some compelling reason, I don't tend to dictate how you implement things. So, if you've got a working graphics subsystem that's better than what we've already got, I'm happy to let you try merging it or adapting the ideas into our codebase using new code. How you want to do it, is fine by me. My basic policy is that I like to see a couple of small-ish patches from anyone that hasn't contributed before. It helps me get a feel for your coding style, and assures that we're all moving in the same direction. After those initial steps, if you're still interested, I'm happy to allow you to commit directly to CVS. How does that sound? > Let me know what you all think. > Mark Smith ---Brett. > On Thu, Sep 18, 2008 at 5:05 PM, Jonathan Ferro > <jon...@ya...> wrote: > Several years ago I posted an idea for an algorithm based on > computing half-routes (starting from stations an only going > one direction) but I've never proved to myself that the > filtering needed (to combine them into full routes and not > conflict with other trains in a corp) would be practical. I > think that was the last time it was openly discussed, and I've > never looked into the code to see how that would fit with the > current game-state internals. > > -- Jonathan > > > > > ----- Original Message ---- > From: brett lentz <wak...@gm...> > To: Development list for Rails: an 18xx game > <rai...@li...> > Sent: Thursday, September 18, 2008 8:10:11 AM > Subject: Re: [Rails-devel] track/route awareness > > On Thu, Sep 18, 2008 at 2:49 AM, Michał Bażyński > <ba...@tl...> wrote: > > hello, > > is anybody working on things like recognizing legal track > builds or > > calculating revenue? not that I am ready to announce I > intend to do it, > > but if it's a work in progress already it won't make sense > for me to > > look into that problem at all... > > > > mike bazynski > > > Nobody has stepped forward to work on route awareness. We > have a > basic implementation for matching legal plays by tracking > which sides > of each hex have track, and lining them up to the sides of > each other > hex that has track. > > If you would like to work on route calculation, you're welcome > to it. > > ---Brett. |
|
From: Mark S. <mar...@gm...> - 2008-09-18 23:49:06
|
I will get around to putting my JAR file together and determining the best place to put it so that it can be retrieved and reviewed by you and anyone else interested. I had seen your SVG stuff, but I must admit I did not pay it a lot of attention. I probably should take another look at that aspect. As for keeping both options (User Select Route) and (Auto Generate Route) open is a viable alternative, but the first easier option is the User Select Route. The Auto Generate Route from a UI perspective is just a different method for selecting the actual points in the route, the graphical display method is the same regardless. As for your method for accepting new code contributors, your patches method is fine with me. I will get a fresh copy of your code base this weekend, and see what jumps out at me. With regards towards codebase merging, I will want to do a basic review of your current one and come up with a reasonable strategy to implement, and not disrupt your current intentions of transistioning to the network based plans you have in mind. More thoughts to come over the weekend. Mark On Thu, Sep 18, 2008 at 7:49 PM, Brett Lentz <wak...@gm...> wrote: > On Thu, 2008-09-18 at 19:09 -0500, Mark Smith wrote: > > I have reviewed what your Rails project does with the board, and the > > fact that you make use of GIF images for the tiles, tokens, etc. I see > > at least two distinct issues with your current implemenation, one is > > the tokens are just a circle of a specific color. If you look at 1835, > > or 1837 there are minor companies that share the SAME color, so that > > it is very hard to tell from your map which minor company starts > > where. The other issue as I know from your forum has not yet been > > solved is scaling the map up and down in size. > > > > My approach was to use the track connections, station locations, > > types, and stuff to draw the board and tiles via Vector Graphics. This > > gives me not only a very clean drawing, but one that can scale up and > > down in size with little extra coding efforts. > > Looks like you missed the SVG tiles we have. We're using Batik to handle > the rendering of SVG tiles. > > Much of the drawing code is fairly basic and there are several known > issues that make me want to try rewriting large sections of it. However, > you're welcome to take on that task. It sounds like we've got a lot of > similar ideas on how it should be done. :-) > > > The tokens I draw are filled circles with the company > > Abbreviation/Number centered in the token. I also draw my default size > > larger, about the same size as the tiles if you hold them up to the > > screen. One other advantage is that since I draw the track segment by > > segment, I can draw routes for different trains in different colors, > > so that you can tell at a glance if they conflict, and the program > > will know if they would re-use track and say "NAY, no re-use buddy!". > > But I have not gotten it to that specific point yet. but I am close to > > actually implementing a way to have the user pick out the routes. > > > > Interesting. Perhaps you'd like to work on merging codebases? > > > Now this last point brings up a philosphical question of game > > implementation. Should the Player pick the routes, or should the > > computer auto-calculate the routes to maximize income? The game rules > > specifically state the player picks routes, and has to live with the > > mistake. However, sometimes in some games (like 1853), you may want to > > maximize your mail run, or maximize your revenue at different times. > > > > I would prefer to support both options, and leave it up to the user to > select an option at runtime. > > > > If there is intrest, I could be enticed to provide a copy of a JAVA > > JAR File that could be run to see if my approach sparks interest. I > > feel that it might be worth considering a possible integration of my > > map/tile routines into Rails... but only the current product looks > > promising to those currently implementing. > > > > There's definitely interest. We can always use more people contributing > code. :-) > > In general, if you're contributing code, I (usually) leave the > implementation details up to you. Unless there's some compelling reason, > I don't tend to dictate how you implement things. > > So, if you've got a working graphics subsystem that's better than what > we've already got, I'm happy to let you try merging it or adapting the > ideas into our codebase using new code. How you want to do it, is fine > by me. > > My basic policy is that I like to see a couple of small-ish patches from > anyone that hasn't contributed before. It helps me get a feel for your > coding style, and assures that we're all moving in the same direction. > > After those initial steps, if you're still interested, I'm happy to > allow you to commit directly to CVS. > > How does that sound? > > > > Let me know what you all think. > > Mark Smith > > > ---Brett. > > > On Thu, Sep 18, 2008 at 5:05 PM, Jonathan Ferro > > <jon...@ya...> wrote: > > Several years ago I posted an idea for an algorithm based on > > computing half-routes (starting from stations an only going > > one direction) but I've never proved to myself that the > > filtering needed (to combine them into full routes and not > > conflict with other trains in a corp) would be practical. I > > think that was the last time it was openly discussed, and I've > > never looked into the code to see how that would fit with the > > current game-state internals. > > > > -- Jonathan > > > > > > > > > > ----- Original Message ---- > > From: brett lentz <wak...@gm...> > > To: Development list for Rails: an 18xx game > > <rai...@li...> > > Sent: Thursday, September 18, 2008 8:10:11 AM > > Subject: Re: [Rails-devel] track/route awareness > > > > On Thu, Sep 18, 2008 at 2:49 AM, Michał Bażyński > > <ba...@tl...> wrote: > > > hello, > > > is anybody working on things like recognizing legal track > > builds or > > > calculating revenue? not that I am ready to announce I > > intend to do it, > > > but if it's a work in progress already it won't make sense > > for me to > > > look into that problem at all... > > > > > > mike bazynski > > > > > > Nobody has stepped forward to work on route awareness. We > > have a > > basic implementation for matching legal plays by tracking > > which sides > > of each hex have track, and lining them up to the sides of > > each other > > hex that has track. > > > > If you would like to work on route calculation, you're welcome > > to it. > > > > ---Brett. > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: brett l. <wak...@gm...> - 2008-09-19 00:12:31
|
2008/9/18 Mark Smith <mar...@gm...>: > I will get around to putting my JAR file together and determining the best > place to put it so that it can be retrieved and reviewed by you and anyone > else interested. > If it's not too big ( > 1 MB), e-mail it directly to me, and I can throw it up on the rails webspace that sourceforge gives us. > I had seen your SVG stuff, but I must admit I did not pay it a lot of > attention. I probably should take another look at that aspect. > > As for keeping both options (User Select Route) and (Auto Generate Route) > open is a viable alternative, but the first easier option is the User Select > Route. The Auto Generate Route from a UI perspective is just a different > method for selecting the actual points in the route, the graphical display > method is the same regardless. > Agreed. > As for your method for accepting new code contributors, your patches method > is fine with me. I will get a fresh copy of your code base this weekend, and > see what jumps out at me. > > With regards towards codebase merging, I will want to do a basic review of > your current one and come up with a reasonable strategy to implement, and > not disrupt your current intentions of transistioning to the network based > plans you have in mind. > At this point, I don't think adding in your code will disrupt my efforts for quite a while. I was going to rework the drawing code once the lower level bits were ready. If you're going to be working in that area, it just means there will be less for me to do because you've already gotten to it. ;-) > More thoughts to come over the weekend. > > Mark > ---Brett > On Thu, Sep 18, 2008 at 7:49 PM, Brett Lentz <wak...@gm...> wrote: >> >> On Thu, 2008-09-18 at 19:09 -0500, Mark Smith wrote: >> > I have reviewed what your Rails project does with the board, and the >> > fact that you make use of GIF images for the tiles, tokens, etc. I see >> > at least two distinct issues with your current implemenation, one is >> > the tokens are just a circle of a specific color. If you look at 1835, >> > or 1837 there are minor companies that share the SAME color, so that >> > it is very hard to tell from your map which minor company starts >> > where. The other issue as I know from your forum has not yet been >> > solved is scaling the map up and down in size. >> > >> > My approach was to use the track connections, station locations, >> > types, and stuff to draw the board and tiles via Vector Graphics. This >> > gives me not only a very clean drawing, but one that can scale up and >> > down in size with little extra coding efforts. >> >> Looks like you missed the SVG tiles we have. We're using Batik to handle >> the rendering of SVG tiles. >> >> Much of the drawing code is fairly basic and there are several known >> issues that make me want to try rewriting large sections of it. However, >> you're welcome to take on that task. It sounds like we've got a lot of >> similar ideas on how it should be done. :-) >> >> > The tokens I draw are filled circles with the company >> > Abbreviation/Number centered in the token. I also draw my default size >> > larger, about the same size as the tiles if you hold them up to the >> > screen. One other advantage is that since I draw the track segment by >> > segment, I can draw routes for different trains in different colors, >> > so that you can tell at a glance if they conflict, and the program >> > will know if they would re-use track and say "NAY, no re-use buddy!". >> > But I have not gotten it to that specific point yet. but I am close to >> > actually implementing a way to have the user pick out the routes. >> > >> >> Interesting. Perhaps you'd like to work on merging codebases? >> >> > Now this last point brings up a philosphical question of game >> > implementation. Should the Player pick the routes, or should the >> > computer auto-calculate the routes to maximize income? The game rules >> > specifically state the player picks routes, and has to live with the >> > mistake. However, sometimes in some games (like 1853), you may want to >> > maximize your mail run, or maximize your revenue at different times. >> > >> >> I would prefer to support both options, and leave it up to the user to >> select an option at runtime. >> >> >> > If there is intrest, I could be enticed to provide a copy of a JAVA >> > JAR File that could be run to see if my approach sparks interest. I >> > feel that it might be worth considering a possible integration of my >> > map/tile routines into Rails... but only the current product looks >> > promising to those currently implementing. >> > >> >> There's definitely interest. We can always use more people contributing >> code. :-) >> >> In general, if you're contributing code, I (usually) leave the >> implementation details up to you. Unless there's some compelling reason, >> I don't tend to dictate how you implement things. >> >> So, if you've got a working graphics subsystem that's better than what >> we've already got, I'm happy to let you try merging it or adapting the >> ideas into our codebase using new code. How you want to do it, is fine >> by me. >> >> My basic policy is that I like to see a couple of small-ish patches from >> anyone that hasn't contributed before. It helps me get a feel for your >> coding style, and assures that we're all moving in the same direction. >> >> After those initial steps, if you're still interested, I'm happy to >> allow you to commit directly to CVS. >> >> How does that sound? >> >> >> > Let me know what you all think. >> > Mark Smith >> >> >> ---Brett. >> >> > On Thu, Sep 18, 2008 at 5:05 PM, Jonathan Ferro >> > <jon...@ya...> wrote: >> > Several years ago I posted an idea for an algorithm based on >> > computing half-routes (starting from stations an only going >> > one direction) but I've never proved to myself that the >> > filtering needed (to combine them into full routes and not >> > conflict with other trains in a corp) would be practical. I >> > think that was the last time it was openly discussed, and I've >> > never looked into the code to see how that would fit with the >> > current game-state internals. >> > >> > -- Jonathan >> > >> > >> > >> > >> > ----- Original Message ---- >> > From: brett lentz <wak...@gm...> >> > To: Development list for Rails: an 18xx game >> > <rai...@li...> >> > Sent: Thursday, September 18, 2008 8:10:11 AM >> > Subject: Re: [Rails-devel] track/route awareness >> > >> > On Thu, Sep 18, 2008 at 2:49 AM, Michał Bażyński >> > <ba...@tl...> wrote: >> > > hello, >> > > is anybody working on things like recognizing legal track >> > builds or >> > > calculating revenue? not that I am ready to announce I >> > intend to do it, >> > > but if it's a work in progress already it won't make sense >> > for me to >> > > look into that problem at all... >> > > >> > > mike bazynski >> > >> > >> > Nobody has stepped forward to work on route awareness. We >> > have a >> > basic implementation for matching legal plays by tracking >> > which sides >> > of each hex have track, and lining them up to the sides of >> > each other >> > hex that has track. >> > >> > If you would like to work on route calculation, you're welcome >> > to it. >> > >> > ---Brett. >> >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X