From: Erik V. <eri...@hc...> - 2008-02-26 18:38:29
|
Just to let you know that I am working on the behaviour on cities/stations during tile upgrades, making sure that the tokens end up in the proper place, etc. This was needed for the 18EU company start in/after phase 5, where a home base must be chosen, possibly on a multi-city tile. This should also take care of 1830 OO tile upgrades and the Erie home base. Proper token drawing is a related but more complicated issue, perhaps I may find inspiration to attack that one too. One thing I'm doing is separating the dual use of the Station class: for defining a city/station on a generic tile, and for a city on a tile actually laid on some hex, possibly having tokens. For the latter purpose I'm adding a new City class. The reason is clarity - the current dual use is too confusing for me. Erik |
From: Jeff B. <jef...@gm...> - 2008-02-26 19:26:13
|
I noticed in 1870 that a company could place a station marker on a spot that should be reserved for another company's start location. You might want to check this out while you're improving this area. Also, this might be a little further than you're working right now, but consider the impact of needing to place a bonus token on a particular city in a multi-city tile. On Tue, Feb 26, 2008 at 11:38 AM, Erik Vos <eri...@hc...> wrote: > Just to let you know that I am working on the behaviour on cities/stations > during tile upgrades, making sure that the tokens end up in the proper > place, etc. > This was needed for the 18EU company start in/after phase 5, > where a home base must be chosen, possibly on a multi-city tile. > This should also take care of 1830 OO tile upgrades and the Erie home > base. > > Proper token drawing is a related but more complicated issue, > perhaps I may find inspiration to attack that one too. > > One thing I'm doing is separating the dual use of the Station class: > for defining a city/station on a generic tile, and for a city on > a tile actually laid on some hex, possibly having tokens. > For the latter purpose I'm adding a new City class. > The reason is clarity - the current dual use is too confusing for me. > > Erik > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: Brett L. <wak...@gm...> - 2008-02-26 19:30:17
|
Also, in the case of 1870, there is a standard and a variant way of handling destination tokens. The standard rule is that destination tokens don't occupy one of the normal city spaces. The variant is they do. So, we're going to need this to be very flexible and configurable. ---Brett. On Tue, 2008-02-26 at 12:26 -0700, Jeff Bowers wrote: > I noticed in 1870 that a company could place a station marker on a > spot that should be reserved for another company's start location. > You might want to check this out while you're improving this area. > > Also, this might be a little further than you're working right now, > but consider the impact of needing to place a bonus token on a > particular city in a multi-city tile. > > On Tue, Feb 26, 2008 at 11:38 AM, Erik Vos <eri...@hc...> wrote: > Just to let you know that I am working on the behaviour on > cities/stations > during tile upgrades, making sure that the tokens end up in > the proper > place, etc. > This was needed for the 18EU company start in/after phase 5, > where a home base must be chosen, possibly on a multi-city > tile. > This should also take care of 1830 OO tile upgrades and the > Erie home base. > > Proper token drawing is a related but more complicated issue, > perhaps I may find inspiration to attack that one too. > > One thing I'm doing is separating the dual use of the Station > class: > for defining a city/station on a generic tile, and for a city > on > a tile actually laid on some hex, possibly having tokens. > For the latter purpose I'm adding a new City class. > The reason is clarity - the current dual use is too confusing > for me. > > Erik > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel ---Brett. I CAN BE ROBBED BUT NEVER DENIED, I TOLD MYSELF. WHY WORRY? 'I too cannot be cheated,' snapped Fate. SO I HAVE HEARD. (Colour of Magic) |
From: Erik V. <eri...@hc...> - 2008-02-26 21:54:38
|
> Also, in the case of 1870, there is a standard and a variant way of > handling destination tokens. > > The standard rule is that destination tokens don't occupy one of the > normal city spaces. > > The variant is they do. 1870 is beyond my horizon right now, but it'll be considered when the time comes... Erik. |
From: Brett L. <wak...@gm...> - 2008-02-26 22:14:21
|
On Tue, 2008-02-26 at 22:54 +0100, Erik Vos wrote: > > Also, in the case of 1870, there is a standard and a variant way of > > handling destination tokens. > > > > The standard rule is that destination tokens don't occupy one of the > > normal city spaces. > > > > The variant is they do. > > 1870 is beyond my horizon right now, but it'll be considered when the time > comes... > > Erik. Of course. The point isn't 'this feature is needed to implement 1870'. The point is, there is at least one game that has requirements for token placement outside of town spots on a map hex. We need to either define an additional "town" spot for map hexes that allow token placements for certain game mechanics, such as destination runs. Or we need to define tokens in a way that allows them to be used in places other than city spots. The big thing I don't want to see us do is specializing the tokens into "town tokens" and "non-town tokens". The board games don't make this distinction, and I see no reason for us to do it either. These are generic enough mechanisms that I don't think 1870 is the only game that uses them. So, if you're going to be cleaning up the token code, this is something to keep in mind and, if you don't code it directly, leave room in your design to add it later. ---Brett. If you're going to do something tonight that you'll be sorry for tomorrow morning, sleep late. -- Henny Youngman |
From: Erik V. <eri...@hc...> - 2008-02-26 22:58:43
|
Brett, You're of course right. I have already implemented a bonus token for 18AL (the Coalfield token), and it is an off-city token there. Anyway, all tokens classes inherit from Token/TokenI, so where flexibility does not yet exist, it should not be hard to attain. Erik. > -----Original Message----- > From: rai...@li... > [mailto:rai...@li...] On Behalf > Of Brett Lentz > Sent: Tuesday 26 February 2008 23:14 > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Cities and stations > > > On Tue, 2008-02-26 at 22:54 +0100, Erik Vos wrote: > > > Also, in the case of 1870, there is a standard and a > variant way of > > > handling destination tokens. > > > > > > The standard rule is that destination tokens don't occupy > one of the > > > normal city spaces. > > > > > > The variant is they do. > > > > 1870 is beyond my horizon right now, but it'll be > considered when the time > > comes... > > > > Erik. > > Of course. The point isn't 'this feature is needed to implement 1870'. > The point is, there is at least one game that has > requirements for token > placement outside of town spots on a map hex. > > We need to either define an additional "town" spot for map hexes that > allow token placements for certain game mechanics, such as destination > runs. Or we need to define tokens in a way that allows them to be used > in places other than city spots. > > The big thing I don't want to see us do is specializing the > tokens into > "town tokens" and "non-town tokens". The board games don't make this > distinction, and I see no reason for us to do it either. > > These are generic enough mechanisms that I don't think 1870 > is the only > game that uses them. So, if you're going to be cleaning up the token > code, this is something to keep in mind and, if you don't code it > directly, leave room in your design to add it later. > > > ---Brett. > > > If you're going to do something tonight that you'll be sorry > for tomorrow > morning, sleep late. > -- Henny Youngman > > > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: Erik V. <eri...@hc...> - 2008-02-26 21:53:25
|
I noticed in 1870 that a company could place a station marker on a spot that should be reserved for another company's start location. You might want to check this out while you're improving this area. Yes, currently their is no relationship whatsoever between token placement and tile city location. There are just one or two standard spots. Also, this might be a little further than you're working right now, but consider the impact of needing to place a bonus token on a particular city in a multi-city tile. Yes, we need some algorithm to find a free spot.... |