Roadmap
For details of the game see 18NL documentation.
Implementation of edge cases / rules ambiguities, see document on special tiles and token lays.
-
New implementation to exchange the president certificate, for details see document on selling the president certificate.
-
A new game option allows to select the Westermann ruling that NF/PfB token powers are restricted to the token lay step
A Windows exe wrapper based on launch4j added.
Added implementation that allows correct handling of the sell restriction during the first round of an 18xx games. There is a new GameOption that decides when the sell restriction ends.
<GameOption name="FirstRoundSellRestriction" values="First Round,First Stock Round" default="First Round" />
More information are found [here] (FirstRoundSellRestriction).
During the correction mode tile lays are possible anywhere on the map. Only upgrades are possible, no downgrades. Terrain costs are ignored and (if required) have to be assigned to a company with a cash correction.
Token lays are similar, it is possible to lay a token for any company on any free slot of the map. Token lays however take the costs into account, so if the token lay should be free of charge, it has to be adjusted by a cash correction.
Done: Total worth calculation works in all cases, except after share price changes.
TODO:
- Define Valuable interface and implement that to Portofolios and Certificates
There was a discussion on dev list ('Specification of implementation levels for different 18xx games in Rails') how to better define the maturity and implementation of 18xx games.
TODO:
- Finalize discussion and implement that in Rails
TODO:*
- Question: What is the general definition of a route? Currently: Run 2 train, if Revenue > 0, there is a route
- Route check => Forced Train Purchase (2.1)
Idea is to base it on Google Play Game Services. Currently Java on Desktop not supported directly, but it is possible to use the REST-API. For REST there is a Java 1.6 support and several REST-API client libraries.
The current Rails save file uses Java persistency approach. This has several drawbacks (difficult to evolve over time, not easy to edit/read). Replacement via a XML/JSON based approach.
Discussed with Martin Brumm and John Tamplin on dev list ('Support needed: New complex Tiles and Maps)
Based on ideas from the Perl code of John Tamplin define the creation of svg-files from the definitions in Tile.xml.
Either replace batik library (for SVG) display by a more lightweight SVG library OR leverage power of batik to replace Swing graphic functionality. Currently the output quality is sub-par.
Remark: Salamander SVG library showed in a first test that is no possible replacement.
The last missing piece of functionality for 1830.
Done: Prototype available, testing possible in 18NL (and 18Lummer)
TODO:
- Add missing functionality (2.1)
Create a class hierarchy for the swing UI classes similar to the one for the Rails core engine.
Done: Define interfaces (UIRoot, UIItem)
TODO (2.1): Implement interfaces
Let RailsItem implement Model by Default and drop RailsModel abstract class.
Advantage: This reduces complexity of the class hierarchy with little performance cost.
TODO (2.1): Should this be done?
TODO (2.1): Discussed with Martin Brumm on dev list ('Terrain XML definitions)
-
Define Terrain in Defaults:
<Defaults> <Terrain type="mountain" cost="80" /> <Terrain type="river" cost="40" /> </Defaults> -
Terrain on Hexes:
<Hex name="D8" tile="0"/> <Terrain type="mountain"/> </Hex> -
Terrain on Edges:
<Edge from="D8" to="E9"> <Terrain type="river" /> </Edge> -
This also allows moving the impassable definitions from Hexes to Edges:
<Edge from="D8" to="E9"> <Impassable /> </Edge>
Requested by Oliver Heck on dev list ('Tile orientation in 1835'): Add rotation attribute that allows game-specific rotation defaults for tiles.
TODO (2.1): Still open...
TODO (2.1):
Discussed on dev list ('Variants and GameOptions', '1835 Schlesien'):
-
An example of the GameVariant tag:
<Variant name="Schlesien"> <Option name="StartRound" value="Clemens" suggest="yes"/> <Option name="LDIncome" value="30M"/> </Variant>
This would give the user the checkbox to activate the Schlesien variant and would do the following:
* A GameOption "Schlesien" to true, that can be used itself as a value
in a IfOption tag.
* In the option display to the user the options are preset according to
the variant. If suggest is not set, the option is grayed out.
If suggest is set to yes, the user can deviate, however there will be a
visual indication that the option is preset by the variant.
-
Further refinements:
-
If variants are mutually exclusive they can be defined with a group attribute.
<Variant name="Schlesien" group="map"> <Variant name="Hessian" group="map">In this case the variants with the same group name will be selected from a dropdown list.
-
If several variants can be chosen simultaneously and they set the same GameOption the variant which does not have suggest takes precedence. If neither has suggest, the first in ordering will take precendence, but a warning will be issued.
-
- Create an abstraction that defines a CertificateType (currently attributes president, shares, certificateCount)
- Each certificate belongs to a Certificate Type and a Company
- Then clean up the current mess, including the static map, which is only for backward compatibility for early 1.x versions
- OBB auto-close after laying of both tiles