Re: [Rails-devel] Operating Round

[Brett <wak...@ea...>]

On Wed, 2005-05-04 at 18:16 +0200, Erik Vos wrote:
> 
> Other responsibilities of these middle-layer classes are:
> - all validation of player actions (though many invalid actions
> will be impossible if the UI is set up correctly - see below).

Correct.  I see this as a task for both layers.

The UI ought to block invalid input from the users, and the middle-layer
ought to attempt to disallow invalid input from the UI.

> - keeping track of who has the turn (I have not used the Turn class,
> I think we don't need it).

I agree. We probably don't need it if GameManager is handling this
function. Though, if used, it does provide another point of
extensibility. Not that we really need that, but it's an option.

> These classes allow marking allowed actions in the UI in detail.
> For instance, to check if the current Player can buy a share
> of a given company from the Pool you could call
>     isCompanyBuyable (company, pool);

I've approached this slightly differently in the Swing UI.

There's only two buttons: Buy and Selling.

When you select a particular company and player, and press the Buy
button, if the company isn't started yet, it buys the president's share,
if it is started, it buys the next available share from any pool.

I'm planning on making this a bit more granular once I add displays for
each pool, but for now it keeps things simple and effective.

> This method does not yet include a check that the player has enough
> money (this is checked, though, in buyShare), but I will
> add such checks later.

I think conditions like these only need checking once. The tricky part
is, where should the checking be?

Do we want to use exception throwing to pass errors deeper in the class
hierarchy up to the higher level classes for handling?

> 
> My suggestion would be to mark the background of clickable fields
> with a light colour (e.g. pale yellow), and those that are have been
> selected (or pre-selected: the player or company that has the turn)
> with a darker colour (e.g. green).
> 

I don't think the selection color really matters so long as the UI only
has a single item selected at any given time. 

Right now my Swing UI allows a single selection in each of the three
status boxes, which isn't good, but is easily correctable.

> I have not touched the XML in a while: there is a lot hardcoded now.
> This is high on my list to do, but I'll first try to complete the
> round/turn management, as this deeply affects the UI code that Brett is 
> currently working so hard on.

Sounds good to me.

I've pulled the hex code from Colossus and put it into ui/hexmap . The
main reason I like their hex code is because, just like us, they need to
handle what's on each side of each hex. Thankfully, for us it's just
entrances and exits rather than different types of terrain. But it's a
great starting point because much of the math and drawing is already
coded.

I'm working on getting more familiar with it so that I can work on
drawing the map while you're finishing up the turn/round logic.

Do we happen to have anyone on the list familiar with programming hex-
maps already?


---Brett. 

If it doesn't smell yet, it's pretty fresh. -- Dave Johnson, on dead
seagulls