rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[Erik V. <eri...@xs...>]

 

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Wednesday 12 May 2010 00:37
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation details for revenue calculation

1835:
Hamburg: (Multiple) RevenueBonus(es)
Open Question here if and how an invalid orientation of the brown Hamburg
tile 
can be prevented.

[EV] I will look at that. Guess the orientation can be fixed in TileSet.xml.

1851
Birmingham: does not exist until Phase 4
Most likely this should be implemented outside of the revenue part. I would 
prefer that the hex is empty until phase 4 and that the phase change
triggers 
the lay of that tile.

[EV] I'll think about it. 

Re: [Rails-devel] Implementation details for revenue calculation

[alexti <al...@sh...>]

Hi Stefan,

On Tue, 11 May 2010 16:37:18 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> 1856
> Bonus tokens: When and how to create the RevenueBonus?
> (=> StaticRevenueModifier)
>
> 18AL
> Bonus tokens and Named trains: When and how to create the RevenueBonus?
> (=> StaticRevenueModifier)

My approach is to include "token" requirements to the bonus definition.  
For example, for port token in 1856 I have an entry in bonus table (that  
gives +20 to the city) with 2 requirements: (1) hex must contain port  
token; (2) company must have port token. Tokens are transferred during the  
private company sales and (when applicable) due to direct token sales.

Alex.

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. (web.de) <ste...@we...>]

Alex:
that is one idea, which I use for the simple RevenueBonuses, which lay on a 
Hex or Tile.

For the more complex cases I prefer a "push" approach to a "pull" approach:
The objects that change reveneues have to register themselves as 
RevenueModifiers. Those are two Interfaces (static and a dynamic version) 
which have to be implemented by the objects that want to modify the revenue 
results. 

The major obstacle is my neglectable knowledge about Tokens and BonusTokens in 
Rails. Thus I do not want to change anything there close to the next release.

Stefan


>
> My approach is to include "token" requirements to the bonus definition.
> For example, for port token in 1856 I have an entry in bonus table (that
> gives +20 to the city) with 2 requirements: (1) hex must contain port
> token; (2) company must have port token. Tokens are transferred during the
> private company sales and (when applicable) due to direct token sales.
>
> Alex.
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[alexti <al...@sh...>]

Stefan,

I was just throwing ideas around. My solutions are often influenced by a  
need to run a lot of "what-if" scenarios. So, for example, when I'm  
determining where a company should place a port token, I would run the  
optimal route search using a vector of different bonus definitions  
(corresponding to the placement of port token on different tiles). That  
makes it much more efficient that run separate searches. Those  
considerations wouldn't be applicable to Rails.

Alex.

On Fri, 14 May 2010 10:03:43 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> Alex:
> that is one idea, which I use for the simple RevenueBonuses, which lay  
> on a
> Hex or Tile.
>
> For the more complex cases I prefer a "push" approach to a "pull"  
> approach:
> The objects that change reveneues have to register themselves as
> RevenueModifiers. Those are two Interfaces (static and a dynamic version)
> which have to be implemented by the objects that want to modify the  
> revenue
> results.
>
> The major obstacle is my neglectable knowledge about Tokens and  
> BonusTokens in
> Rails. Thus I do not want to change anything there close to the next  
> release.
>
> Stefan
>
>
>>
>> My approach is to include "token" requirements to the bonus definition.
>> For example, for port token in 1856 I have an entry in bonus table (that
>> gives +20 to the city) with 2 requirements: (1) hex must contain port
>> token; (2) company must have port token. Tokens are transferred during  
>> the
>> private company sales and (when applicable) due to direct token sales.
>>
>> Alex.
>>
>> ---------------------------------------------------------------------------
>> ---
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/