Menu
▾
▴
rails-devel
|
From: <ia...@co...> - 2005-10-08 23:53:59
|
> 1. Train ownership limits (Brett Lentz) > I'm feeling the need to step away from the stupid repaint issues with the Map for a while. > > I was looking over the handling of train purchasing, and I'm not seeing any definitions in the XML for what the maximum number of trains a company can own. > > Has this not been defined yet? > > I'm pretty sure I can add it in without too much hassle, but I just want to make sure I'm not duplicating efforts before I do. > > I think just a maxNumTrainsOwned="4" property is all we need. > > Is there any 18xx game that bases the number of trains a company can own on something other than what trains are available? > > Before we go inextricably tying these things together in the code, that might be handy to know. ;-) > Train limits may vary both by company (or company type) and phase of the game. You probably have to encode a lookup table that takes company and pahse, and returns the train limit. Doing so in a fashion that can let you specify defaults/large ranges at one go may help those who have to produce definition files later. A general note on my long silence: I have been very busy with my job over the last six months, and have had no time for out-of-hours coding. I've been following the mailing list, and it sound like things are progressing well. Iain. |
|
From: Erik V. <eri...@hc...> - 2005-10-14 13:09:18
|
> I was looking over the handling of train purchasing, and I'm
> not seeing any definitions in the XML for what the maximum
> number of trains a company can own.
>
> Has this not been defined yet?
No, but I'm about to start to work out the Phases,
to which IMO the train limits will be linked.
> I'm pretty sure I can add it in without too much hassle, but
> I just want to make sure I'm not duplicating efforts before I do.
>
> I think just a maxNumTrainsOwned="4" property is all we need.
I don't think there is a need for this once we have the phases in place.
> Is there any 18xx game that bases the number of trains a
> company can own on something other than what trains are available?
Yes, type of company: many games have minor companies
which typically have a train limit of 2 or 1.
And merger companies (like the Prussian in 1835) often
may have an extra train above what normal major companies may have.
Because of this, train limits should IMO be linked to CompanyType,
and be an array with an element per phase.
For instance:
<CompanyType ....>
....
<TrainLimit number="4,4,3,2"/>
</CompanyType>
where the last number ("2") applies for any later phase as well.
> Before we go inextricably tying these things together in the
> code, that might be handy to know. ;-)
Keep in mind, that the way company types are defined now is
by creating a dummy company, which in fact processes most of
the company-type related properties.
This dummy company is cloned to create each real company,
whereby each company-type property can be overridden.
For instance, in 1835 the Prussian would get an additional line
<Company name="Pr" ...>
....
<TrainLimit number="0,0,4,3"/>
(the first two numbers are immaterial because the Pr cannot operate
before the 4-trains run).
Erik.
|
|
From: John A. T. <ja...@ja...> - 2005-10-14 13:40:44
|
On Fri, 14 Oct 2005, Erik Vos wrote:
> Because of this, train limits should IMO be linked to CompanyType,
> and be an array with an element per phase.
>
> For instance:
> <CompanyType ....>
> ....
> <TrainLimit number="4,4,3,2"/>
> </CompanyType>
>
> where the last number ("2") applies for any later phase as well.
Keep in mind that companies may change "types" -- ie, in 1826 a company
starts as a 5-share company then may convert to a 10-share company once it
reaches its destination (so somewhere there needs to be descriptions of
the rules for conversion). In 18US, a company may start as a 1-share
company (a private), become a 4-share company as soon as it has a legal
route, become a 5-share company, then a 10-share, and finally may become
part of a system that has 20 shares. The train limits for each of these
may be different (although in practice it is usually 2 or 3 different
values).
You can also have private companies which influence the train limit for
the owning or assigned company.
My personal feeling is that it will be too difficult to describe in XML
every possible way this can be done, and a better approach is to implement
that in Java, with part of the files distributed for a game being .class
files which can be loaded with ClassLoader. That was the approach I took
for a partially-completed Cosmic Encounter long ago -- the basic timing
issues were codified, but all the powers that allow you to break the rules
in specific ways were implemented directly in Java.
--
John A. Tamplin ja...@ja...
770/436-5387 HOME 4116 Manson Ave
Smyrna, GA 30082-3723
|
|
From: Ian K. <ke...@UD...> - 2005-10-14 18:50:03
|
John A. Tamplin wrote: > My personal feeling is that it will be too difficult to describe in XML > every possible way this can be done, and a better approach is to implement > that in Java, with part of the files distributed for a game being .class > files which can be loaded with ClassLoader. That was the approach I took > for a partially-completed Cosmic Encounter long ago -- the basic timing > issues were codified, but all the powers that allow you to break the rules > in specific ways were implemented directly in Java. <delurking> Distributing .class files as part of the game configuration defeats the purpose of using XML, since it makes it that much harder for users to fix or tweak existing games or to create their own games using similar properties. I would recommend instead using an existing Java scripting language, such as Rhino, Jython, or LuaJava, which are imo ideally suited for this purpose. This would provide the same degree of flexibility while still keeping the configuration binary-free. Pure Java would of course be faster, but execution speed should not be a real issue here, since these will most likely be short scripts that run only at a handful of specific times in the game logic. </delurking> -Ian |
|
From: Erik V. <eri...@hc...> - 2005-10-14 13:54:48
|
> > For instance:
> > <CompanyType ....>
> > ....
> > <TrainLimit number="4,4,3,2"/>
> > </CompanyType>
> >
> > where the last number ("2") applies for any later phase as well.
>
> Keep in mind that companies may change "types" -- ie, in 1826
> a company
> starts as a 5-share company then may convert to a 10-share
> company once it
> reaches its destination (so somewhere there needs to be
> descriptions of
> the rules for conversion). In 18US, a company may start as a 1-share
> company (a private), become a 4-share company as soon as it
> has a legal
> route, become a 5-share company, then a 10-share, and finally
> may become
> part of a system that has 20 shares. The train limits for
> each of these
> may be different (although in practice it is usually 2 or 3 different
> values).
>
This is one of the many aspects we have not yet really thought deeply about.
Sure we need to find a way to model that.
> You can also have private companies which influence the train
> limit for
> the owning or assigned company.
I think this would be just a PrivateCompany attribute.
> My personal feeling is that it will be too difficult to
> describe in XML
> every possible way this can be done, and a better approach is
> to implement
> that in Java, with part of the files distributed for a game
> being .class
> files which can be loaded with ClassLoader. That was the
> approach I took
> for a partially-completed Cosmic Encounter long ago -- the
> basic timing
> issues were codified, but all the powers that allow you to
> break the rules
> in specific ways were implemented directly in Java.
Yes, we will have to do the more special stuff in Java classes.
We already have two special classes to handle the 1830-style
and the 1835-style opening rounds.
Game-special classes will certainly be needed for 18US,
but IMO the 1826-style minor/major company conversion is now
common enough that a generic implementation looks worth while.
Probably by creating a special PublicCompany subclass (the company class
name must already be specified in the <CompanyType> XML tag).
As Brett already mentioned: we are focussing on 1830, while
keeping an open eye on other games. But we don't try to solve
everything in this stage.
Erik.
|
|
From: John A. T. <ja...@ja...> - 2005-10-14 14:41:32
|
On Fri, 14 Oct 2005, Erik Vos wrote:
> Yes, we will have to do the more special stuff in Java classes.
> We already have two special classes to handle the 1830-style
> and the 1835-style opening rounds.
>
> Game-special classes will certainly be needed for 18US,
> but IMO the 1826-style minor/major company conversion is now
> common enough that a generic implementation looks worth while.
> Probably by creating a special PublicCompany subclass (the company class
> name must already be specified in the <CompanyType> XML tag).
If you don't want to have phase/company transitions implemented in Java in
general (and certainly there could be one or two "standard"
implementations which use some XML data structure to drive their work),
then I think you will have to go with a full state machine that can update
attributes in arbitrary objects as it transitions to states.
> As Brett already mentioned: we are focussing on 1830, while
> keeping an open eye on other games. But we don't try to solve
> everything in this stage.
I understand the desire to get something working quickly. However, it
seems likely to result in having to rewrite large sections later to
accomodate game mechanics we already know about today, even ignoring
future games that may introduce new concepts.
Nick Wedd's rule difference list provides a single source that covers most
of the different behaviors that need to be implemented. I strongly
suggest coming up with a way to handle everything listed there in the
architecture besides just leaving it for future recoding.
--
John A. Tamplin ja...@ja...
770/436-5387 HOME 4116 Manson Ave
Smyrna, GA 30082-3723
|
|
From: Brett L. <wak...@ea...> - 2005-10-14 20:38:52
|
> I understand the desire to get something working quickly. However, it > seems likely to result in having to rewrite large sections later to > accomodate game mechanics we already know about today, even ignoring > future games that may introduce new concepts. I'll be the first to admit that I've actually only played a small number of 18xx games: 1830, 1856, 1870, and 2038. I've read through the rules for 18Scan and 18US, but that's not quite the same as playing them. When looking at how to implement specific things, I look at it as choosing one of two paths. Either we can implement a design that includes a way to support many 18xx games, or if we can't do that, we can implement things in such a way that we attempt to minimize how much rewriting we have to do later. That's not to say there will be more writing to do later, but that whatever we do now attempts to conflict as little as possible with what we need to add in the future. We do acknowledge that there are a TON of special case rules across the 18xx games. The first logical step toward making implementation of them all easier is to find as much common ground between them as we can. Thus, we have the 1830-style and 1835-style auction (start round) classes as one example of this. As far as train ownership limits and rusting goes, we should try to do the same. I think Iain's e-mail had the right idea on train ownership: >Train limits may vary both by company (or company type) and phase of the game. You >probably have to encode a lookup table that takes company and phase, and returns >the train limit. Doing so in a fashion that can let you specify defaults/large ranges >at one go may help those who have to produce definition files later. One way to handle this is to add a couple properties/methods within the CompanyI, TrainI, and PhaseI interfaces: setNewTrainLimit(int newLimit) rustsTrains(int whichPhase, int whichTrains, int whichCompany) ... etc. And then, in XML define which cross-section of these actually applies to a given game. This way the code can call whichever method it needs to properly implement the game logic for a given game. PublicCompany and PrivateCompany are derived from Company, so they both can own trains, stock, and just about anything else already. The actual algorithm for the rusting and limit checking will probably need to be put into GameManager or some other similar place. Would that allow the kind of flexibility that we're looking for? ---Brett. |
|
From: John A. T. <ja...@ja...> - 2005-10-15 05:04:57
|
On Fri, 14 Oct 2005, Brett Lentz wrote:
> I think Iain's e-mail had the right idea on train ownership:
>
>> Train limits may vary both by company (or company type) and phase of
>> the game. You probably have to encode a lookup table that takes company
>> and phase, and returns the train limit. Doing so in a fashion that can
>> let you specify defaults/large ranges at one go may help those who have
>> to produce definition files later.
That is a good start, but it still doesn't cover everything. A number of
games trigger such things by other criteria, although you can get around
that by making what rails think of as a phase a cross product of what
the game calls a phase and whatever else in the game triggers changes. Of
course, your phase table can quickly explode into a huge table that way
(in 18US there are many different things that trigger events, and some of
them are timed from some trigger [for example, after a trigger the 3
trains are still available but at the end of the OR they are removed so
you have one last chance to buy them]).
That is why I was suggesting that doing it for all games would require
essentially code to implement, not a few fields tacked onto the objects
and more than a simple lookup table.
> One way to handle this is to add a couple properties/methods within the
> CompanyI, TrainI, and PhaseI interfaces:
>
> setNewTrainLimit(int newLimit)
> rustsTrains(int whichPhase, int whichTrains, int whichCompany)
> ... etc.
>
> And then, in XML define which cross-section of these actually applies to
> a given game. This way the code can call whichever method it needs to
> properly implement the game logic for a given game.
That's fine, assuming the XML can encode all that information. As I said,
I have my doubts.
> PublicCompany and PrivateCompany are derived from Company, so they both
> can own trains, stock, and just about anything else already.
A number of games have privates that allow the train limit to be
increased, either by the owner or a designated company (and in some cases
the designated company can be changed each OR), as well as having
alternate uses for the company (ie, in 18VA).
Admittedly 18xx is not nearly as "weird" in this respect as the powers in
Cosmic Encounter are, but I spent much time trying to come up with some
generalized data representation of all the things they allowed you to do
and finally decided it couldn't be done reasonably. I settled on
standardizing sequence points during the turn and the API to ask the
powers if they had something to do at those sequence points. The main
code knew how to handle timing conflicts between powers, but what was
actually done (and importantly the user interface for asking the user what
they wanted to do) was simply Java code associated with each power (in
fact I wound up putting image and text data in the class as static data,
so all the powers were just .class files in a jar).
> The actual algorithm for the rusting and limit checking will probably
> need to be put into GameManager or some other similar place.
Well, if you have those calls and GameManager updates all the companies
with the new limit, I would think they take care of what happens
themselves.
Note that in several games rusting is unusual -- in 1844, non-regional
trains become regional trains before going away entirely; in 1846 phase I
trains get one extra run after phase III trains are purchased but not if a
phase IV train is bought first; in 18MEX 4-trains get one final run after
they rust but no other trains do; etc.
Also, be aware that at a couple of games have very different rules for
train discarding -- in 2830 for example, you can freely discard any
obsolete ship at the beginning of a turn, and that is the only way you can
ever get rid of them (other than being over the limit). Another game
(don't remember which one off the top of my head) requires a maintenance
payment for obsolete trains and if you won't or can't pay it the train
goes away.
For every rule you can think of, there is probably a game that does it
very differently than the others.
In short, I think it would be best to build a structure that allows
arbitrary rules to be implemented. Trying to implement a subset seems
like it will only lead to starting over at some point (or simply deciding
it won't support a large number of games) since this is a pretty major
piece of the infrastructure. That said, I am the newbie here and it is
unlikely I can provide any coding beyond the tile rendering in the near
term, so do it how you like.
--
John A. Tamplin ja...@ja...
770/436-5387 HOME 4116 Manson Ave
Smyrna, GA 30082-3723
|
|
From: Erik V. <eri...@hc...> - 2005-10-14 22:28:19
|
I'm not too worried about all of this. The current architecture is pretty flexible, and quite some features of not yet included games have already been partially implemented or at least foreseen in the current code. Surely we will have to change code every now and then. I don't see that as a major problem. Even now we have code that we once thought to be useful, but turns out to be unused or replaced by newer code, and so is a candidate for removal. For me, continuous refactoring is a natural component of incremental development work, which is what we are doing here. One very important thing is to be rigorous in keeping a strict model/view division. Erik. > -----Original Message----- > From: rai...@li... > [mailto:rai...@li...] On Behalf Of > Brett Lentz > Sent: 14 October 2005 21:39 > To: rai...@li... > Subject: RE: [Rails-devel] Train ownership limits > > > I understand the desire to get something working quickly. > However, it > > seems likely to result in having to rewrite large sections later to > > accomodate game mechanics we already know about today, even > ignoring > > future games that may introduce new concepts. > > > I'll be the first to admit that I've actually only played a > small number of 18xx games: 1830, 1856, 1870, and 2038. > > I've read through the rules for 18Scan and 18US, but that's > not quite the same as playing them. > > When looking at how to implement specific things, I look at > it as choosing one of two paths. Either we can implement a > design that includes a way to support many 18xx games, or if > we can't do that, we can implement things in such a way that > we attempt to minimize how much rewriting we have to do later. > > That's not to say there will be more writing to do later, but > that whatever we do now attempts to conflict as little as > possible with what we need to add in the future. > > We do acknowledge that there are a TON of special case rules > across the 18xx games. The first logical step toward making > implementation of them all easier is to find as much common > ground between them as we can. Thus, we have the 1830-style > and 1835-style auction (start round) classes as one example of this. > > As far as train ownership limits and rusting goes, we should > try to do the same. > > I think Iain's e-mail had the right idea on train ownership: > > >Train limits may vary both by company (or company type) and > phase of the game. You > >probably have to encode a lookup table that takes company > and phase, and returns > >the train limit. Doing so in a fashion that can let you > specify defaults/large ranges > >at one go may help those who have to produce definition files later. > > > One way to handle this is to add a couple properties/methods > within the CompanyI, TrainI, and PhaseI interfaces: > > setNewTrainLimit(int newLimit) > rustsTrains(int whichPhase, int whichTrains, int whichCompany) > ... etc. > > And then, in XML define which cross-section of these actually > applies to a given game. This way the code can call whichever > method it needs to properly implement the game logic for a given game. > > PublicCompany and PrivateCompany are derived from Company, so > they both can own trains, stock, and just about anything else already. > > The actual algorithm for the rusting and limit checking will > probably need to be put into GameManager or some other similar place. > > > Would that allow the kind of flexibility that we're looking for? > > ---Brett. > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > 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