Menu
▾
▴
rails-devel
|
From: Stefan F. <ste...@we...> - 2012-09-02 07:28:01
|
Several other changes have been implemented recently: *** Removed old (customized) ClassLoader code There has been a customized ClassLoader for Rails, which was inherited from the Colossus project. As most of the functions were not required for Rails I have removed most of the that old code now. Most likely this will allow to use Webstart to distribute Rails2.0 test releases. *** ChangeStack simplified I have decided to separate the Report and Comment facilities from the ChangeStack. This makes it possible to add the facility to comment the end of an operating round without making it a separate ChangeSet. This again allowed to simplify the ChangeStack implementation. *** Management of Cash refactored Similar to the new portfolios, money is stored inside a Wallet (more on the details behind the scene in a separate mail). This easily allows to store all kind of CountableItems, for which money is only one example (so in principle it is easy that Rails supports several currencies). To move money from one owner to the other the following static methods are used: Currency.wire(MoneyOwner from, int amount, MoneyOwner to) Currency.fromBank(int amount, MoneyOwner to) Currency.toBank(MoneyOwner from, int amount) The return value is the formatted String of the amount transferred and can be used for the message to the reportWindow. Those replace the direct creation of a CashMove(...). |
|
From: Erik V. <eri...@xs...> - 2012-09-02 10:34:50
|
Hi Stefan, A few minor comments: > This easily allows to store all kind of CountableItems, for which money is only > one example (so in principle it is easy that Rails supports several currencies). Ah good. We still had no way to handle the Tresham-style Company Credits (1825 et al.). I suppose we now have. > To move money from one owner to the other the following static methods > are used: > > Currency.wire(MoneyOwner from, int amount, MoneyOwner to) > Currency.fromBank(int amount, MoneyOwner to) > Currency.toBank(MoneyOwner from, int amount) I hope the Bank is also a MoneyOwner? Erik |
|
From: Stefan F. <ste...@we...> - 2012-09-02 13:59:24
|
Erik, thanks, quick replies below. Stefan On 09/02/2012 12:34 PM, Erik Vos wrote: > Hi Stefan, > > A few minor comments: > >> This easily allows to store all kind of CountableItems, for which money is > only >> one example (so in principle it is easy that Rails supports several > currencies). > > Ah good. We still had no way to handle the Tresham-style Company Credits > (1825 et al.). I suppose we now have. This is one possibility: Model the Company Credits as another currency. It is easy to identify for each transaction which currency to use. However I still believe that the easiest way is to use one joint currency and simply modify the end-of-game condition by adding all company treasuries to the bank and check if the bank is broken. If I remember correctly there is no other real game effect from using those Company Credits (all transactions between players and companies are forbidden anyway). > >> To move money from one owner to the other the following static methods >> are used: >> >> Currency.wire(MoneyOwner from, int amount, MoneyOwner to) >> Currency.fromBank(int amount, MoneyOwner to) >> Currency.toBank(MoneyOwner from, int amount) > > I hope the Bank is also a MoneyOwner? Sure Bank is a MoneyOwner (but not the BankPortfolios like IPO). The latter are only short cuts, which do not require a reference to bank to be used. However it might make the code easier to assume that IPO/Pool etc. have their own cash wallet to make the item buying code easier: Then the counterparty of the item transaction is identical to the counterparty of the accompanying cash transaction. A BankMoneyModel would then aggregate the sub-wallets for display and checking the game end condition. I will reconsider that as soon as I break up the Round classes into smaller units. |
|
From: John D. G. <jd...@di...> - 2012-09-02 18:21:31
|
On 2012-09-02 09:16, Mike Bourke wrote: > "(all transactions between players and companies are forbidden anyway)." > > Not so. Companies can buy private railways and other such from players and > are expected to do so, depending on which 18xx game you are playing. Without > this ability, there is no way for a company to be able to place a port > marker, for example (since by the time the bank seizes control of such > facilities, the port company is closed). I have only seen company credits in Tresham's own games: 1825, 1829, and 1853. And in those games, railroads do not buy in private companies. > Is not the paying of a dividend (half or full) a transaction between > shareholding players and the company in which the shares are owned? No. The bank pays either players, the railroad, or both. The railroad and players do not pay each other anything. > How about when a company doesn't have enough money for a train and the > President has to pay for it? That is indeed a payment from the president to his company -- but it, too, does not happen in the three Tresham games. Instead, companies with no train which can't arrange a purchase from another company simply fall in price until the owners sell all their shares to the bank (which is allowed). Then the company goes into receivership and is allowed to borrow a train from the bank until it can pay for one. > There are many actions that can be characterized as transactions between > players and companies that are not only not forbidden but are mandatory > elements of the game. And none of them exist in games with company credits. > As for using the total of company treasuries to determine whether or not the > bank is broken, doesn't that ignore the primary point where money is > supposed to accumulate within the game - in the player's hands? The point is that company credits, when they exist, are not supposed to count toward breaking the bank. Thus if you change a game that uses credits by giving the companies ordinary cash, then when determining whether the bank has broken you have to count as if all the cash in company treasuries were still in the bank. Actually I don't recommend combining the types of money this way because it creates another inaccuracy. The smallest company credit "bill" is £10, so all company treasuries are supposed to be constrained to multiples of 10. |
|
From: Erik V. <eri...@xs...> - 2012-09-02 20:56:18
|
> Actually I don't recommend combining the types of money this way because > it creates another inaccuracy. The smallest company credit "bill" is £10, so all > company treasuries are supposed to be constrained to multiples of 10. I agree. Erik. |
|
From: Erik V. <eri...@xs...> - 2012-09-02 20:30:09
|
> However it might make the code easier to assume that IPO/Pool etc. have > their own cash wallet to make the item buying code easier: > Then the counterparty of the item transaction is identical to the counterparty > of the accompanying cash transaction. To me, that sounds like making life more complicated rather than making it simpler. Why then not have the Bank portfolios contain a reference to the Bank Wallet? Or indeed, include into every Portfolio a reference to its owner's Wallet. Erik. |
|
From: Stefan F. <ste...@we...> - 2012-09-02 21:05:44
|
It might sound more complicated, but it is a consequence of the indirect
access to Wallets and Portfolios.
The link between the Wallet and the Owner is defined once and forever by
creating a Wallet with the Owner as the parent.
It does not matter where the Wallet lives (e.g. inside a variable of the
owner itself, inside a PortfolioModel or stored at a completely
different object).
At the time of adding money the Owner is NOT asked for its wallet, but
the wallet for the according owner is provided by the WalletManager by
asking for the correct Wallet for the (Owner, Type) combination.
A potential code snippet for an aggregate BankMoneyModel class:
private Wallet<Currency> bankWallet;
private Wallet<Currency> ipoWallet;
private Wallet<Currency> poolWallet;
public BankMoneyModel(Bank bank) {
bankWallet = Wallet.create(bank, "wallet", Currency.class);
ipoWallet = Wallet.create(bank.getIpo(), "wallet", Currency.class);
poolWallet = Wallet.create(bank.getPool(), "wallet", Currency.class);
bankWallet.addModel(this);
ipoWallet.addModel(this);
poolWallet.addModel(this);
}
public int getCash() {
return bankWallet.value() + ipoWallet.value() + poolWallet.value();
}
In the example above you could wire money to Bank, Pool or Ipo and it
has the same net effect to the BankMoneyModel.
The MoneyOwner interface is only a helper/legacy interface to allow an
easy access the cash value.
On 09/02/2012 10:30 PM, Erik Vos wrote:
>> However it might make the code easier to assume that IPO/Pool etc. have
>> their own cash wallet to make the item buying code easier:
>> Then the counterparty of the item transaction is identical to the
> counterparty
>> of the accompanying cash transaction.
>
> To me, that sounds like making life more complicated rather than making it
> simpler.
> Why then not have the Bank portfolios contain a reference to the Bank
> Wallet?
> Or indeed, include into every Portfolio a reference to its owner's Wallet.
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
|
|
From: Erik V. <eri...@xs...> - 2012-09-02 21:19:44
|
Then I don't see why this WalletManager could not, when asked for the IPO
wallet, return the Bank wallet.
Perhaps it's just me, but I don't see any benefit, just problems, with
splitting up the Bank cash this way.
public BankMoneyModel(Bank bank) {
bankWallet = Wallet.create(bank, "wallet", Currency.class);
ipoWallet = bankWallet; // redundant code, of course, but I hope you
get the point.
poolWallet = bankWallet;
bankWallet.addModel(this);
}
Erik.
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Sunday, September 02, 2012 11:06 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Rails2.0: Further Changes
>
> It might sound more complicated, but it is a consequence of the indirect
> access to Wallets and Portfolios.
>
> The link between the Wallet and the Owner is defined once and forever by
> creating a Wallet with the Owner as the parent.
>
> It does not matter where the Wallet lives (e.g. inside a variable of the
owner
> itself, inside a PortfolioModel or stored at a completely different
object).
>
> At the time of adding money the Owner is NOT asked for its wallet, but the
> wallet for the according owner is provided by the WalletManager by asking
> for the correct Wallet for the (Owner, Type) combination.
>
> A potential code snippet for an aggregate BankMoneyModel class:
>
> private Wallet<Currency> bankWallet;
> private Wallet<Currency> ipoWallet;
> private Wallet<Currency> poolWallet;
>
> public BankMoneyModel(Bank bank) {
> bankWallet = Wallet.create(bank, "wallet", Currency.class);
> ipoWallet = Wallet.create(bank.getIpo(), "wallet", Currency.class);
> poolWallet = Wallet.create(bank.getPool(), "wallet",
Currency.class);
> bankWallet.addModel(this);
> ipoWallet.addModel(this);
> poolWallet.addModel(this);
> }
>
> public int getCash() {
> return bankWallet.value() + ipoWallet.value() + poolWallet.value();
}
>
> In the example above you could wire money to Bank, Pool or Ipo and it has
> the same net effect to the BankMoneyModel.
>
> The MoneyOwner interface is only a helper/legacy interface to allow an
easy
> access the cash value.
>
> On 09/02/2012 10:30 PM, Erik Vos wrote:
> >> However it might make the code easier to assume that IPO/Pool etc.
> >> have their own cash wallet to make the item buying code easier:
> >> Then the counterparty of the item transaction is identical to the
> > counterparty
> >> of the accompanying cash transaction.
> >
> > To me, that sounds like making life more complicated rather than
> > making it simpler.
> > Why then not have the Bank portfolios contain a reference to the Bank
> > Wallet?
> > Or indeed, include into every Portfolio a reference to its owner's
Wallet.
> >
> > Erik.
> >
> >
> > ----------------------------------------------------------------------
> > --------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> > Discussions will include endpoint security, mobile security and the
> > latest in malware threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
>
>
>
----------------------------------------------------------------------------
--
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware
threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Stefan F. <ste...@we...> - 2012-09-02 21:45:56
|
General remark first:
To understand my approach it is important that I try to construct robust
and simple core elements, which do not take into account all special
rules, but provide a few hooks to allow the creation of special rules
without changing the core mechanisms.
It often might seem simpler to drop some restrictions of the core engine
and add the special rules inside the core engine. However this makes the
core engine less robust and might fail at some other places.
So I usually prefer to allow a little bit more complexity at the outer
layers if I can keep the core simple and unchanged.
Specific remark here:
In the current definition there is a one-to-one relationship between
(owner,type) <-> portfolio<type> and wallet<type>
Buy your question below is a good one: Would it be possible to for a n:1
relationship? For the core mechanism it is possible, as currently we
only ask for the wallet/portfolio given the owner and type.
However there is at least one use case with a disadvantage:
A general correction mechanism, which shows all portfolios containing
one type of items and allow moving back and forward between them. For
this use case a n:1 relationship complicates things a bit, but it is not
impossible to solve the issues.
The code would be different however:
bankWallet = Wallet.create(bank, "wallet", Currency.class)
bankWallet.addOtherOwner(bank.getIpo());
bankWallet.addOtherOwner(bank.getPool());
I am undecided, as it is possible to achieve the same result with a
slightly more complicated solution for the (special) Bank case.
Stefan
On 09/02/2012 11:19 PM, Erik Vos wrote:
> Then I don't see why this WalletManager could not, when asked for the IPO
> wallet, return the Bank wallet.
> Perhaps it's just me, but I don't see any benefit, just problems, with
> splitting up the Bank cash this way.
>
> public BankMoneyModel(Bank bank) {
> bankWallet = Wallet.create(bank, "wallet", Currency.class);
> ipoWallet = bankWallet; // redundant code, of course, but I hope you
> get the point.
> poolWallet = bankWallet;
> bankWallet.addModel(this);
> }
>
> Erik.
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Sunday, September 02, 2012 11:06 PM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Rails2.0: Further Changes
>>
>> It might sound more complicated, but it is a consequence of the indirect
>> access to Wallets and Portfolios.
>>
>> The link between the Wallet and the Owner is defined once and forever by
>> creating a Wallet with the Owner as the parent.
>>
>> It does not matter where the Wallet lives (e.g. inside a variable of the
> owner
>> itself, inside a PortfolioModel or stored at a completely different
> object).
>>
>> At the time of adding money the Owner is NOT asked for its wallet, but the
>> wallet for the according owner is provided by the WalletManager by asking
>> for the correct Wallet for the (Owner, Type) combination.
>>
>> A potential code snippet for an aggregate BankMoneyModel class:
>>
>> private Wallet<Currency> bankWallet;
>> private Wallet<Currency> ipoWallet;
>> private Wallet<Currency> poolWallet;
>>
>> public BankMoneyModel(Bank bank) {
>> bankWallet = Wallet.create(bank, "wallet", Currency.class);
>> ipoWallet = Wallet.create(bank.getIpo(), "wallet", Currency.class);
>> poolWallet = Wallet.create(bank.getPool(), "wallet",
> Currency.class);
>> bankWallet.addModel(this);
>> ipoWallet.addModel(this);
>> poolWallet.addModel(this);
>> }
>>
>> public int getCash() {
>> return bankWallet.value() + ipoWallet.value() + poolWallet.value();
> }
>>
>> In the example above you could wire money to Bank, Pool or Ipo and it has
>> the same net effect to the BankMoneyModel.
>>
>> The MoneyOwner interface is only a helper/legacy interface to allow an
> easy
>> access the cash value.
>>
>> On 09/02/2012 10:30 PM, Erik Vos wrote:
>>>> However it might make the code easier to assume that IPO/Pool etc.
>>>> have their own cash wallet to make the item buying code easier:
>>>> Then the counterparty of the item transaction is identical to the
>>> counterparty
>>>> of the accompanying cash transaction.
>>>
>>> To me, that sounds like making life more complicated rather than
>>> making it simpler.
>>> Why then not have the Bank portfolios contain a reference to the Bank
>>> Wallet?
>>> Or indeed, include into every Portfolio a reference to its owner's
> Wallet.
>>>
>>> Erik.
>>>
>>>
>>> ----------------------------------------------------------------------
>>> --------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond.
>>> Discussions will include endpoint security, mobile security and the
>>> latest in malware threats.
>>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and threat
>> landscape has changed and how IT managers can respond. Discussions will
>> include endpoint security, mobile security and the latest in malware
> threats.
>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
|
|
From: Erik V. <eri...@xs...> - 2012-09-02 22:18:44
|
> However there is at least one use case with a disadvantage: > A general correction mechanism, which shows all portfolios containing one > type of items and allow moving back and forward between them. For this > use case a n:1 relationship complicates things a bit, but it is not impossible to > solve the issues. Money is not an item but an amount, I'd say. Nothing moves, just equal amounts get added and subtracted. To me, it's fundamentally different from all other Rails objects, and should be treated in its own way. > The code would be different however: > bankWallet = Wallet.create(bank, "wallet", Currency.class) > bankWallet.addOtherOwner(bank.getIpo()); > bankWallet.addOtherOwner(bank.getPool()); Indeed. > I am undecided, as it is possible to achieve the same result with a slightly > more complicated solution for the (special) Bank case. Your way, nothing should happen if a wallet gets a negative amount. You can no longer do this check at the lowest level, because the bank only breaks if the total amount of all its wallets becomes negative, not if any one of these does. So that kind of check must always be done at a higher (the owner's) level, as a separate action after each move at a lower level. Not sure how you are going to manage that. To prevent such complications, I'd rather have a little bit more complexity at a lower level (if needed at all, but I don't think so). Erik. |
|
From: John D. G. <jd...@di...> - 2012-09-03 01:27:15
|
On 2012-09-02 15:18, Erik Vos wrote: > Your way, nothing should happen if a wallet gets a negative amount. You can > no longer do this check at the lowest level, because the bank only breaks > if the total amount of all its wallets becomes negative, not if any one of > these does. So that kind of check must always be done at a higher (the > owner's) level, as a separate action after each move at a lower level. Not > sure how you are going to manage that. I've been assuming that if you attempt a money move that would make a Wallet negative, it would throw an exception; but the bank's Wallet would be a special case, and would allow the move but set a BankHasBroken flag. |
|
From: Stefan F. <ste...@we...> - 2012-09-03 20:30:58
|
I try to collect several replies on Money and Bank issues to John's and Erik's comments. On 09/03/2012 12:18 AM, Erik Vos wrote: > > Money is not an item but an amount, I'd say. Nothing moves, just equal > amounts get added and subtracted. To me, it's fundamentally different from > all other Rails objects, and should be treated in its own way. > For me an Integer amount can move as well (and in Java Integers can be first-class citizens as well). But I prefer the term to "wire" the Integer money amount ;-) However Money gets a different treatment to Trains, as it is not "Ownable" but "Countable" and stored in a "Wallet" and not a "Portfolio". Further all classes that get own money get an additional Interface "MoneyOwner" and this takes Money above the level of a Train as there is no such thing as a "TrainOwner". > On 2012-09-02 15:18, Erik Vos wrote: >> Your way, nothing should happen if a wallet gets a negative amount. You can >> no longer do this check at the lowest level, because the bank only breaks >> if the total amount of all its wallets becomes negative, not if any one of >> these does. So that kind of check must always be done at a higher (the >> owner's) level, as a separate action after each move at a lower level. Not >> sure how you are going to manage that. > The check for the bank broken will be inside a Model (BankWalletModel) that contains the BankWallet(s) as member(s). On 09/03/2012 03:27 AM, John David Galt wrote: > I've been assuming that if you attempt a money move that would make a Wallet > negative, it would throw an exception; but the bank's Wallet would be a > special case, and would allow the move but set a BankHasBroken flag. Wallets currently does not check for negative amounts. I am considering adding the option to a Wallet to only allow positive values, but that is not the case now. *** Some further thoughts on my proposal with the separate Wallets for IPO and Pool in addition to a Bank wallet. You should not judge the proposal so much on its implementation, but on its outcome: If done correctly ... * To transfer money to the Bank you can use either Bank or IPO or Pool as the counterparty. This especially allows a symmetric behavior that if you buy e.g. a Train from the IPO you can pay to the IPO. Otherwise you would always have to remember that you buy from IPO, but pay to Bank (thus the parent of IPO). If you buy a train from another company, you will pay the other company and not the parent of that company. * If you ask Bank or IPO or Pool for getCash() you will get the total amount of money in the bank as the answer. * The check for bank broken will always work on the correct total amount of the bank money. So for the main use cases it behaves like one wallet, it is only the internal wiring which uses three wallets. The only disadvantage is the use case of a correction mechanisms as suggested in a previous mail. Here would have to aggregate the three wallets manually again. *** 1825 (et.al) company credits: On 09/02/2012 08:21 PM, John David Galt wrote: > The point is that company credits, when they exist, are not supposed to count > toward breaking the bank. Thus if you change a game that uses credits by > giving the companies ordinary cash, then when determining whether the bank has > broken you have to count as if all the cash in company treasuries were still > in the bank. That was my intention for a simple implementation. > > Actually I don't recommend combining the types of money this way because it > creates another inaccuracy. The smallest company credit "bill" is £10, so all > company treasuries are supposed to be constrained to multiples of 10. Actually I have not considered that as a game mechanic, but simply a matter of no-need for smaller bills: I had the impression that there is no allowed transaction for companies that requires smaller amounts, but if there are cases we have to consider that rule: What actually happens in those cases (overpayment, rounding)? Stefan |
|
From: Erik V. <eri...@xs...> - 2012-09-03 20:55:49
|
> You should not judge the proposal so much on its implementation, but on > its outcome: If done correctly ... Its implementation bears upon efficiency, and IMO that what is at stake here. > This especially allows a symmetric behavior that if you buy e.g. a Train > from the IPO you can pay to the IPO. Yes. I do not put that into question. > So for the main use cases it behaves like one wallet, it is only the > internal wiring which uses three wallets. Accepting all your previous reasoning, I still don't see why the IPO and Pool wallets cannot be (or point to) the same object as the Bank's wallet. The split still seems completely unnecessary to me. If it is an inevitable consequence of your architecture, then too bad for that architecture. But let's stop arguing. Erik. |
|
From: Erik V. <eri...@xs...> - 2012-09-03 15:17:44
|
> It often might seem simpler to drop some restrictions of the core engine and > add the special rules inside the core engine. However this makes the core > engine less robust and might fail at some other places. > So I usually prefer to allow a little bit more complexity at the outer layers if I > can keep the core simple and unchanged. Of course, you want to have the layer where Undo/Redo are executed as simple as possible. That's the lowest layer, I understand. Another consideration is that the services offered to the application layer should be as simple as possible, in the sense that the application programmer should not have to worry about technical details. Such as how wallets are constructed. Now we have (at least) three layers (in my view). The terminology is mine (and I have used a similar concept successfully several times throughout my career in IT): 1. The application layer. In Rails, that's mostly the Round classes. 2. The service layer. Companies, Portfolios and such. I think the Managers belong here too. 3. The lowest layer (core). That is (in Rails) where you register States, move items around, manage Undo stacks etc. In my opinion, your "little bit more complexity" should be handled in the service layer. If that is what you intend to do, I'm happy. But if you put it in the application layer, then I start worrying. Erik. |
|
From: Stefan F. <ste...@we...> - 2012-09-03 19:45:25
|
Erik: actually I do not think I have changed the layer/package structure substantially. To the contrary I tried to keep most of the terminology and structure of Rails1.x. I mostly agree with your characterization, however I do not agree that the game components classes and the round classes are in different layers. I think that the game logic is shared between the two in the current implementation and it is the correct way to do so. Or better: That there is no correct way to create a strict separation such that the game logic is only kept in one or the other. So my current understand about the Rails structure: 1. There is a core engine layer in rails.game.state, which provides A) The Change/State mechanics B) The Item hierachy C) Portfolio and Wallets are a hybrid of both A) and B) This layer does not assume anything about 18xx games at all and could be used to support any other (board)game computer implementation. 2. The main 18xx classes in rails.game, which provides A) The game components like Bank, Companies, Certificates etc. B) The game mechanics like Rounds C) Managers are a hybrid to link and support A) and B) This layer should support all standard elements of 18xx games, but no special stuff. I intend to split that into sub-packages as rails.game really grew very large. I was considering something like rails.game.components and rails.game.rounds 3. The main classes use components from the following packages A) rails.game.action for game actions B) rails.game.model for components that can be observed by the UI C) rails.game.special for special properties I believe that the separation between 2. and 3. is not a very strong one, as there is a strong interdependence between elements both in 2. and 3. E.g. it would make sense to put the related models and the game components into one package. 4. Then there are two service packages A) The rails.algorithm package for network calculations B) The rails.correction package for correction mechanisms 5. And two utility packages C) The rails.common package for xml parsing and other supporting services D) The rails.util package for further utilities, which do not find anywhere else 6. UI packages in rails.game.ui.* 7. Game specific packages in rails.game.specific.* The dependency structure is: The game engine (2/3) depends on the core(1) and utility(5) The service classes (4) depend on the game engine(2/3) The UI(6) depends on the game engine (2/3) and the service classes (4) Game specific classes either change the game engine(2/3), service classes(4) or the UI(6). > > Now we have (at least) three layers (in my view). The terminology is mine > (and I have used a similar concept successfully several times throughout my > career in IT): > > 1. The application layer. In Rails, that's mostly the Round classes. > > 2. The service layer. Companies, Portfolios and such. I think the Managers > belong here too. > > 3. The lowest layer (core). That is (in Rails) where you register States, > move items around, manage Undo stacks etc. > > In my opinion, your "little bit more complexity" should be handled in the > service layer. If that is what you intend to do, I'm happy. > But if you put it in the application layer, then I start worrying. > > Erik. > |
|
From: Mike B. <com...@ip...> - 2012-09-02 16:16:41
|
"(all transactions between players and companies are forbidden anyway)." Not so. Companies can buy private railways and other such from players and are expected to do so, depending on which 18xx game you are playing. Without this ability, there is no way for a company to be able to place a port marker, for example (since by the time the bank seizes control of such facilities, the port company is closed). Is not the paying of a dividend (half or full) a transaction between shareholding players and the company in which the shares are owned? How about when a company doesn't have enough money for a train and the President has to pay for it? There are many actions that can be characterized as transactions between players and companies that are not only not forbidden but are mandatory elements of the game. As for using the total of company treasuries to determine whether or not the bank is broken, doesn't that ignore the primary point where money is supposed to accumulate within the game - in the player's hands? Mike Bourke Campaign Mastery http://www.campaignmastery.com Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 120901-1, 02/09/2012 Tested on: 3/09/2012 2:16:51 AM avast! - copyright (c) 1988-2012 AVAST Software. http://www.avast.com |
×
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