From: <ia...@co...> - 2005-03-02 13:01:56
|
Route traversal and revenue calculation: I wrote some perl to do this several years ago (avilable at http://www.cosgor.demon.co.uk/Perlbits/revenue.html), it doesn't take long. General comment: Has anyone read the 18xx-softdev archive yet? A lot of good ground was covered there (not all by me ;-)), and I think the discussions here would benefit from using this as a base. Specifically look at the thread(s) on a game definition file. Class structures, general and company: The abstract base class suggestion is almosts right. THe best practice is to define an interface, e.g. CompanyI, which defines the methods that all companies need to implement. You can then have an abstract base class and specific implementation classes for the most common types, but you are free to supply a completely different implementation without the need for inheriting from a specific (abstract base) class. All API methods which work with Company objects should then use CompanyI as the reference type unless a known sub-type is needed. Another advantage of this interface approach is that it permits one class to implement several different functions, e.g. an 1841 company class could implement 'TrainOwnerI', and 'ShareholderI'. In fact an 1830 public company could also implement 'ShareHolderI' to deal with any payments that it could receive from a private company which it owns. On the subject of share structure for companies, why not have a ShareI datatype, and have a 'List<ShareI> getShareStructure()' method on CompanyI? (Notes: a) use of Java5 Generics optional, b) choice of which collection to use also open) A method on ShareI could be 'int dividendForPayout(int payout)' which would calculate the dividend for a given share when the company distributes 'payout' amongst its shareholders. Other possible methods for a share could include 'double getSharePercent()', 'List getValidOwners()' - an 1830 private can be owned by a player or a company, but public company shares may only be held by players (or the bank pool, or the IPO). Iain. |
From: Erik V. <eri...@hc...> - 2005-03-02 19:46:55
|
Iain, > General comment: > > Has anyone read the 18xx-softdev archive yet? A lot of good > ground was covered there (not all by me ;-)), and I think the > discussions here would benefit from using this as a base. > Specifically look at the thread(s) on a game definition file. Just looked again, but it is hard so sort out the few pearls from that mess. The thing I see so far is your data model in message #127, which we indeed would do well to keep handy (I'll print it out). Marco Rocci's summary of the 1830 private auction process in message #478 might also be useful. Any other messages you find worth revisiting? There is one interesting idea that I would add, inspired on message #238 from Gregor Zeitlinger: creating subclasses for game-specific processes. The question is to what extent we can configure options in a config file. At some point things might get so complicated or game-specific that we need to write special code. The idea is to do that in game-specific subclasses of generic classes which handle the more common cases. A strong example is the Ferdinandea Secession in 1841, which I don't think we can make configurable - we will need game-specific code for that. This would mean, that class names should be configurable too: an 1841 game definition file might contain a definition like "PhaseChangeClass=PhaseChange1841" (or the equivalent in XML), assuming that we have a generic (default) class named PhaseChange. Such classes should be instantiated by a class factory. |
From: Brett L. <wak...@ea...> - 2005-03-03 02:40:06
|
For configuring options, I recommend taking a look at Colossus (= http://colossus.sf.net ). I think they do a good job of balancing in-game or pre-game options versus= specialties of variant game types. Granted, their game isn't going to have= quite the extent of "special rules" that we are, but I think it's a good= place to look at for some inspiration. I agree that we're going to have to split out two classes of options:= *mostly* game-independant (e.g. Use an extra optional "6" train, or Bank= starts with X value, etc), and game specific (e.g. Formation of the= Canadian National Railway in 1856). The other option is having a single catch-all user-defined game type where= the user can select the base ruleset (e.g. the user selects that he wants= to play a game with the 1825 ruleset) and from there, certain= customizations are then made available and tailored to what is reasonable= within each ruleset (e.g. an extra 6 train isn't reasonable for a game= that has no 6 trains at all.). Off the top of my head, allowing for a randomly constructed map and= user-defining the total amount of cash in the bank are probably two out of= only a handful of options that is _truly_ game independant. ---Brett. *********** REPLY SEPARATOR *********** On 3/2/2005 at 8:46 PM Erik Vos using eri...@hc... declared: > >There is one interesting idea that I would add, inspired on message #238 >from Gregor Zeitlinger: creating subclasses for game-specific processes. > >The question is to what extent we can configure options in a config file. >At some point things might get so complicated or game-specific that we >need to write special code. >The idea is to do that in game-specific subclasses of generic classes >which handle the more common cases. > >A strong example is the Ferdinandea Secession in 1841, which I don't think >we can make configurable - we will need game-specific code for that. ********** REPLY SEPARATOR END ********** This message sent with 100% recycled electrons. |