From: Stefan F. <ste...@we...> - 2011-08-15 05:41:56
|
Erik: your suggestions/questions below all belong to the same discussion. My design principle for the revenue calculation is the following: A) Implement the general 18xx rules in the core revenue classes in a general way (thus allow variations) and keep performance in mind. B) Implement all specific game rules in specific modifiers, which only implement what is needed. Here I do not take care about performance. All modifiers have to use pre-defined interfaces. This translates to XML: A) All variations of the core rules should be controlled by variables in XML. B) Define specific settings (e.g. hexes, trains) inside the modifier classes. No XML needed. It has the additional benefit to keep the XML clean and focused. It might happen over time that a rule upgrades from the specific to the general category. This was my type A) remark, type B) remarks below ;-) Stefan On Sunday, August 14, 2011 03:21:15 pm Erik Vos wrote: > > > Q4: Do we need a separate type for 1860 halts? And perhaps 1825 halts > > > (see also Q7 below)? > > > > I would only add stopTypes to XML which are already supported. > > So currently we have only city, town and offmap. > > We have already started to work at 18VA and 1825, so I would like to look > at these games anyway. > > After all, the stop properties are only intended to make your life a bit > easier, at least in this matter....:-) For me the stopType is nothing more than a name (for me). I do not like to have something like stopType.equals ("....") inside the core code (type A)). This is similar to the name of a trainType: All attributes have to be defined by attributes, the name does not matter. This for example enables the fact that entities with identical names behave differently across games (think about how 2-trains in 18EU or 1830, H-trains in 1844 or 1826 etc.). > > > I have not checked how you defined the ports in 18EU, but for me they are > > identical to towns and would not need an own stopType. > > That's true for 18EU, and 1841 as well (except that in 1841 ports do not > count as stops in finding a valid route - towns do). > Currently, 18EU ports are defined as towns. Again it does not matter: If the type is only a name, one can define 18EU ports as ports and then define the attributes identical to towns in 18EU. > > 18VA ports are of a different kind. These are not separate stops (for > finding valid route purposes), but add a bonus to the nearby cities (if > tokened) - but only if that city is at one end of a route. > To enforce port cities being at the end of a route, it could be helpful to > add ports as special kind of stops anyway. (This only applies to Baltimore > and Annapolis: you cannot both run through to Philadelphia or Baltimore and > get the port bonus). > On the other hand, if we don't consider 18VA ports as separate entities, I > think we should also remove the 18VA ports from the visible map. As the type is only a name, ports in 18EU are independent of ports in 18VA. However it seems that this is a very specific behavior, thus it will be a modifier => type B) rule, no XML support. > > > Towns can and should always be minor as for standard trains major and > > minor stops are both counted to train reach. > > OK. To be more precise: Actually towns could be defined as major in 1830 as there are no +-trains currently. However as soon as someones adds a plus-train, (s)he would be surprised that it does not behave as expected. > > > All 1825 specific issues are supported by revenue modifiers already, thus > > there does not need a XML support for this. > > > > 1825 modifiers are: > > DoubleHeadingModifier to allow two 2-trains run as a 3 train. > > ScoreTileOnlyOnceModifier to check that each tile is scored only once. > > TerminateAtMajorModifier to only allow runs that start/finish at majors. > > Wouldn't you need something extra to support 1825 halts (on tile #11, in > some kits)? > Only T-trains may (optionally) consider halts as stops, other trains must > ignore halts. > I think a separate scoreType could be helpful here, but perhaps you can do > without. You are right, but I thought that T-trains and tile #11 only exists in some kits, I did not know that they are already included. Again sounds like a modifier, thus no need to support inside XML. > > Erik. > > > > --------------------------------------------------------------------------- > --- FREE DOWNLOAD - uberSVN with Social Coding for Subversion. > Subversion made easy with a complete admin console. Easy > to use, easy to manage, easy to install, easy to extend. > Get a Free download of the new open ALM Subversion platform now. > http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |