rails-devel — List for discussion of Rails development

Re: [Rails-devel] The Player Class

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

I believe this is not an issue with Java.

Also, this is the difference between an array and an ArrayList. Arrays require size to be set at instantiation, ArrayLists size is changable.

---Brett

-----Original Message-----
From: John David Galt <jd...@di...>
Sent: Apr 26, 2005 1:27 PM
To: rai...@li...
Subject: Re: [Rails-devel] The Player Class

Erik Vos wrote:
> Nice, but what is the advantage above a static array?
> Looks a lot easier to me.
> 
> I'm getting the impression that 'static' is synonymous to
> 'not done' here....

I hope so.

The reason for not using static arrays is that they set an unnecessary
upper limit on the number of instances, which can fail when temporary
copies of a class object are created in situations such as copying a
class type (a = b) or when a function returns a value of that type.
Some compilers create these temporary copies when others don't, so it's
simpler and better just to avoid having the limit.

Re: [Rails-devel] The Player Class

[John D. G. <jd...@di...>]

Erik Vos wrote:
> Nice, but what is the advantage above a static array?
> Looks a lot easier to me.
> 
> I'm getting the impression that 'static' is synonymous to
> 'not done' here....

I hope so.

The reason for not using static arrays is that they set an unnecessary
upper limit on the number of instances, which can fail when temporary
copies of a class object are created in situations such as copying a
class type (a = b) or when a function returns a value of that type.
Some compilers create these temporary copies when others don't, so it's
simpler and better just to avoid having the limit.

RE: [Rails-devel] The Player Class

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

> Erik Vos wrote:
> > I'm from a school of thought that classes should be self-managing,
> > which is why I tend to include static arrays and methods to manage
> > the instances of a class inside that class, as I have done 
> in Player. 
> 
> It's not exactly clear to me what you mean by self-managing.

A class that keeps a list of its own instances,
and provides methods to find these instances.
In some cases it might also instantiate them.
 
> Part of my coding philosophy is that, when taking any action 
> that needs
> to be cleaned up afterward (opening a file, allocating heap 
> memory, etc.),
> that action should be represented by a class object with a 
> destructor that
> cleans it up when it goes out of scope.  That way you can't forget it.

Cleanup is automatic in Java, if you remember not to keep
references to no-longer-needed objects.

> But if you mean you want to have a class keep a list of all 
> objects of that
> class, that's easy enough to do without static arrays.  

<snip>

Nice, but what is the advantage above a static array?
Looks a lot easier to me.

I'm getting the impression that 'static' is synonymous to
'not done' here....

Erik.

RE: [Rails-devel] The Player Class

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

I'm still getting the same error.
This method (Options.setPreferredSize(Dimension) )
is indeed missing in my version of Options.

May I suggest to remove .classpath from CVS?
Your setup is somewhat different from mine,
so I can't currently update the whole project.

Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf Of 
> wak...@ea...
> Sent: 26 April 2005 20:47
> To: rai...@li...
> Subject: RE: [Rails-devel] The Player Class
> 
> Hmmmm.... you might have caught me right as I was committing 
> some changes.
> 
> Try doing another checkout/update and see if that fixes it.  
> It's working fine for me right now.
> 
> ---Brett.
> 
> -----Original Message-----
> From: Erik Vos <eri...@hc...>
> Sent: Apr 26, 2005 12:36 PM
> To: rai...@li...
> Subject: RE: [Rails-devel] The Player Class
> 
> > Over the last few days, I've been working on getting the 
> > initial game options working. If you check out the files in 
> > CVS and run the main() method in test/GameTest.java you'll 
> > see the current state of things.
> 
> ... which is:
> 
> java.lang.Error: Unresolved compilation problem: 
> 	The method setPreferredSize(Dimension) is undefined for the type
> Options
> 
> 	at ui.Options.initialize(Options.java:56)
> 	at ui.Options.<init>(Options.java:132)
> 	at test.GameTest.GameInitTest(GameTest.java:12)
> 	at test.GameTest.main(GameTest.java:17)
> Exception in thread "main" 
> 
> so I guess there is something missing in CVS.
> 
> Erik.
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 

Re: [Rails-devel] The Player Class

[John D. G. <jd...@di...>]

Erik Vos wrote:
> I'm from a school of thought that classes should be self-managing,
> which is why I tend to include static arrays and methods to manage
> the instances of a class inside that class, as I have done in Player. 

It's not exactly clear to me what you mean by self-managing.

Part of my coding philosophy is that, when taking any action that needs
to be cleaned up afterward (opening a file, allocating heap memory, etc.),
that action should be represented by a class object with a destructor that
cleans it up when it goes out of scope.  That way you can't forget it.

But if you mean you want to have a class keep a list of all objects of that
class, that's easy enough to do without static arrays.  Here's an example
in C++ of a class that maintains a circular linked list of every instance
of itself.

    class Example;  // to allow pointer declarations

    class Example {

    private:
        Example *prev, *next;
        static Example *first;

    public:
        Example();
        ~Example();

        // whatever other members it will contain

    };

    Example *Example::first = 0;  // The only static member.  Initialize once.

    Example::Example() {

        // If there are any other constructors, they also must contain this code.

        if (first) {

            // Insert the new instance into the circular pointer chain at the
            // end (just before *first).  Notice that first does not change.

            next = first;
            prev = next->prev;
            prev->next = this;
            next->prev = this;
        } else {

            // We're creating the first instance.  For now, prev, next, and
            // first will all point to that one instance.

            prev = this;
            next = this;
            first = this;
        }
    }

    Example::~Example() {
        if (prev == this) {

            // We're deleting the last instance.

            first = 0;
        } else {

            // Unlink this instance from the pointer chain.

            prev->next = next;
            next->prev = prev;

            // If we're deleting *first, update first.

            if (first == this) first = next;
        }
    }

Of course, in a multi-threaded program, both this constructor and destructor
would need locking calls added around their present contents.

RE: [Rails-devel] The Player Class

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

Hmmmm.... you might have caught me right as I was committing some changes.

Try doing another checkout/update and see if that fixes it.  It's working fine for me right now.

---Brett.

-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Apr 26, 2005 12:36 PM
To: rai...@li...
Subject: RE: [Rails-devel] The Player Class

> Over the last few days, I've been working on getting the 
> initial game options working. If you check out the files in 
> CVS and run the main() method in test/GameTest.java you'll 
> see the current state of things.

... which is:

java.lang.Error: Unresolved compilation problem: 
	The method setPreferredSize(Dimension) is undefined for the type
Options

	at ui.Options.initialize(Options.java:56)
	at ui.Options.<init>(Options.java:132)
	at test.GameTest.GameInitTest(GameTest.java:12)
	at test.GameTest.main(GameTest.java:17)
Exception in thread "main" 

so I guess there is something missing in CVS.

Erik.




-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

RE: [Rails-devel] The Player Class

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

> Over the last few days, I've been working on getting the 
> initial game options working. If you check out the files in 
> CVS and run the main() method in test/GameTest.java you'll 
> see the current state of things.

... which is:

java.lang.Error: Unresolved compilation problem: 
	The method setPreferredSize(Dimension) is undefined for the type
Options

	at ui.Options.initialize(Options.java:56)
	at ui.Options.<init>(Options.java:132)
	at test.GameTest.GameInitTest(GameTest.java:12)
	at test.GameTest.main(GameTest.java:17)
Exception in thread "main" 

so I guess there is something missing in CVS.

Erik.

RE: [Rails-devel] Initial Round

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

> Erik Vos wrote:
> > No big deal: just two flags. I agree, that from a 
> structural point of 
> > view it looks better to classify auctions as subrounds of 
> the stock round,
> > as well as nationalisations, the 18EU final exchange round, and
> > the 1841 4-train events can be seen subrounds of the 
> operating round.
> 
> As I see it, not all of these are "rounds" at all.  A round is, or
> should be, a sequence of player turns in each of which that 
> player can,
> or must, make one or more decisions.

I have been using "round" in a very loose way, rather like an abbreviation
for "a procedure complex enough to warrant implementation in a 
(often game-specific) special class". Sorry for the confusion.
Is "procedure" a better term? Or "process"?

> The 1830 start-packet sequence (which I do not call an 
> "auction" because
> it does not consist entirely of bids and passes, and because it may
> contain single-item auctions) takes place during multiple stock turns,
> which may be completed in the first stock round or may span more than
> one stock round with operating rounds in between.  (But each 
> single-item
> auction, if it happens, is a round.)

Yes, this more or less precludes the simple setup that Brett and I
worked out last Sunday. 

So we're back at the "start-packet procedure" being a subprocess
of the stock round...!?
 
> Nationalization (as in 1835) is a simple, single action.  (But the
> sequence of giving each player in turn the option to merge privates/
> minors into the Prussian is a round, and it can happen multiple times.
> When this is triggered by the Prussian forming upon the 
> purchase of the
> first 4 or first 4+4 train, it is a round within a round.)

The Prussian formation is what I was referring to as "nationalisation"
as a subround (I know 1835 uses the term for a different purpose).
Other examples occur in 1826 (Etat, SNCF), 1856 (CGR).

> The 18EU MCFER and the 1841 Ferdinandea Succession are rounds.
> 
> Events such as one company buying a train from another, and mergers in
> games like 1841, should not be considered rounds (in my opinion)
> because once the phasing player or company has begun the event, the
> event contains at most one "turn".  

Right. 

> This includes 1841's forced Tuscan merger.

OK, so in your definition a "round" is something that has "turns".
That makes sense, but I'm not sure if this definition will help us much.
We'll see.
 
> The variety of examples above has convinced me that each game should
> be allowed to define its own private kinds of rounds, and that the
> game entity should be generic enough to allow for them.

Yes, we aren't there yet.
 
> [snip]
> > I don't think 1830 is a good example, as all unsold privates are
> > auctioned at the same time.
 
> Not even!  There is a specific turn sequence, and the turns within
> each auction do not alter the turn sequence in the stock round which
> continues after the auction from where it was before that auction.
> If you need details of this, consult the 18AL/18GA rules, which
> exactly follow the entire 1830 starting-packet procedure.

What I meant is: all privates are open for bidding (except the cheapest
one).
Whereas in 18EU, only one private is open for bidding or buying at any
one point in time, except when a player has the turn to select one.
So there, in your definition, we have rounds within turns.

Erik.

RE: [Rails-devel] The Player Class

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

>I'm from a school of thought that classes should be self-managing,
>which is why I tend to include static arrays and methods to manage
>the instances of a class inside that class, as I have done in Player. 


I agree with you that for some things, this is the right way to go. This 
is especially true for classes that only ever really need one instance, 
such as Bank.

Though, now that I think about it, perhaps Bank should be a totally static 
class?


>About the Player[] allPlayers (I tend to use ArrayLists
>because these do not need to be pre-dimensioned): sure, 
>but my point is: where do we store such an array? 
>I have put it as a static array inside Player (the class, not the instance)
>itself. 


We would store such an array in the initialization code for starting up a new game.

I've already been working a bit on this sort of initialization: see ui/GameLoader.java


>But, as I already have indicated in an earlier post, self-managing classes
>turn out not to fit well with the style of component management and XML
>parsing that we have started to use, so that a PlayerManager class 
>already needs to be considered.

>So I probably (though somewhat reluctantly) have to agree with you....

>Long live the proliferation of classes! :-(

Ok... I've gotten further along in coding the startup UI for a new game. Included with that, I'll pull out the self-managing portions of Player so that it can be used for storing a single player's data. I'll be committing this sometime later today.

Things are starting to look a lot like an actual game. It's quite encouraging.

I've also found a good profiler plugin for Eclipse: http://eclipsecolorer.sourceforge.net/index_profiler.html

This has let me track down the reason for the StockChart's horrible performance. In short, it's because the paintComponent method for each token is being called over and over and over to the point where nothing else is able to be repainted. I'm working on a solution for that as well.


---Brett.

RE: [Rails-devel] Selecting a game

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

> I've just noticed something...
> 
> We don't currently have a method of showing which games are 
> available in order to allow a user to select which game 
> they'd like to play.
> 
> Is it possible to scan the data directory, check the Game.xml 
> files, and return a list of game names?

See java.io.File. 
If a file is a directory, list() returns the names of its contents.

Erik.

RE: [Rails-devel] The Player Class

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

> Over the last few days, I've been working on getting the 
> initial game options working. If you check out the files in 
> CVS and run the main() method in test/GameTest.java you'll 
> see the current state of things.
> 
> However, it looks like the Player class needs some clean-up 
> work done to it before I go too much further. 
> 
> Currently, there are methods that presume the Player is a 
> collection for housing all players' data and there are 
> methods that presume the Player is a singular object.
> 
> I think we need to pick one of these styles rather than 
> cluttering up the class with the ability to work both ways.
> 
> In my opinion, it's very easy to use existing collections to 
> store multiple singular Player objects (ex: Player[] 
> allPlayers). This allows the Player class to focus on housing 
> all the data specific to a single player and makes a bit more 
> logical sense when we have Player extending CashHolder.
> 
> 
> Thoughts?

Yes.

I'm from a school of thought that classes should be self-managing,
which is why I tend to include static arrays and methods to manage
the instances of a class inside that class, as I have done in Player. 

About the Player[] allPlayers (I tend to use ArrayLists
because these do not need to be pre-dimensioned): sure, 
but my point is: where do we store such an array? 
I have put it as a static array inside Player (the class, not the instance)
itself. 
Why not?

Two other considerations were:

1. Player is not very likely to be subclassed, so the usual 
addition of an interface might not be needed. But maybe it is.

2. Static methods are easy because you don't need to carry object 
references around.

But, as I already have indicated in an earlier post, self-managing classes
turn out not to fit well with the style of component management and XML
parsing that we have started to use, so that a PlayerManager class 
already needs to be considered.

So I probably (though somewhat reluctantly) have to agree with you....

Long live the proliferation of classes! :-(

Erik,

[Rails-devel] The Player Class

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

Over the last few days, I've been working on getting the initial game options working. If you check out the files in CVS and run the main() method in test/GameTest.java you'll see the current state of things.

However, it looks like the Player class needs some clean-up work done to it before I go too much further. 

Currently, there are methods that presume the Player is a collection for housing all players' data and there are methods that presume the Player is a singular object.

I think we need to pick one of these styles rather than cluttering up the class with the ability to work both ways.

In my opinion, it's very easy to use existing collections to store multiple singular Player objects (ex: Player[] allPlayers). This allows the Player class to focus on housing all the data specific to a single player and makes a bit more logical sense when we have Player extending CashHolder.


Thoughts?


---Brett.

Re: [Rails-devel] Initial Round

[John D. G. <jd...@di...>]

Erik Vos wrote:
> No big deal: just two flags. I agree, that from a structural point of 
> view it looks better to classify auctions as subrounds of the stock round,
> as well as nationalisations, the 18EU final exchange round, and
> the 1841 4-train events can be seen subrounds of the operating round.

As I see it, not all of these are "rounds" at all.  A round is, or
should be, a sequence of player turns in each of which that player can,
or must, make one or more decisions.

The 1830 start-packet sequence (which I do not call an "auction" because
it does not consist entirely of bids and passes, and because it may
contain single-item auctions) takes place during multiple stock turns,
which may be completed in the first stock round or may span more than
one stock round with operating rounds in between.  (But each single-item
auction, if it happens, is a round.)

Nationalization (as in 1835) is a simple, single action.  (But the
sequence of giving each player in turn the option to merge privates/
minors into the Prussian is a round, and it can happen multiple times.
When this is triggered by the Prussian forming upon the purchase of the
first 4 or first 4+4 train, it is a round within a round.)

The 18EU MCFER and the 1841 Ferdinandea Succession are rounds.

Events such as one company buying a train from another, and mergers in
games like 1841, should not be considered rounds (in my opinion)
because once the phasing player or company has begun the event, the
event contains at most one "turn".  This includes 1841's forced Tuscan
merger.

> I was mainly concerned about how the code that builds the UI will
> know that it has to prepare for an Auction. It looked easier to have it
> start an auction right away, rather than let it start a Stock Round, 
> which then needs to tell the UI "no, we'll have an Auction first."
> But we may end up like this anyway, so your approach may be right
> (see my other post, in which I adhere to your approach).

The variety of examples above has convinced me that each game should
be allowed to define its own private kinds of rounds, and that the
game entity should be generic enough to allow for them.

[snip]
> I don't think 1830 is a good example, as all unsold privates are
> auctioned at the same time.

Not even!  There is a specific turn sequence, and the turns within
each auction do not alter the turn sequence in the stock round which
continues after the auction from where it was before that auction.
If you need details of this, consult the 18AL/18GA rules, which
exactly follow the entire 1830 starting-packet procedure.

[Rails-devel] Selecting a game

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

I've just noticed something...

We don't currently have a method of showing which games are available in order to allow a user to select which game they'd like to play.

Is it possible to scan the data directory, check the Game.xml files, and return a list of game names?

---Brett

RE: [Rails-devel] Initial Round

[Brett L. <bre...@ea...>]

On Sun, 2005-04-24 at 22:59 +0200, Erik Vos wrote:
> > >> 1. The turn order structure ought to be defined in XML 
> > based on Game.
> > >
> > >Here we enter the difficult subject of what to put in the XML
> > >and what in the code, and insofar we are putting stuff in the XML,
> > >how and where we do that (e.g. see my earlier remarks on putting 
> > >the player cash and certificate limits under <Bank>, as I did,
> > >but unconvinced that that was the right way).
> > 
> > 
> > To me, one of the problems we must solve is making our 
> > application extensible by others.
> > One way of doing that is to make a large amount of 
> > configuration available outside the code.
> > So, for me it makes sense to put as much as we can into the XML.
> > 
> > I think that, in the end, what we'll have is effectively an 
> > 18xx markup language.
>  
> Given the ingenuity of 18xx game designers, I'm pretty sure that 
> we will not very often be able to configure a new game by just writing XML.
> Usually some code writing will be involved too.
> 
> Having said that, I agree with the general principle.
> But I'm a bit wary of attempts to be dogmatic about it.
> 
> Complex procedures that, in all its details, are likely unique
> can better be hardcoded. Such as CGR formation in 1856.
> I'm not going to define that in XML!
> Only where we find that other games do the same thing (perhaps with
> small differences that can be parametrised) it makes sense
> to generalise. 
> 
> We'll have to see where to find the balance.
>  


I think we're saying just about the same thing here.

As with my XML example, the assumption is made that the code knows how
to handle special events such as formation of the CGR. I don't even want
to attempt to define every little part of that sort of operation within
the XML.

Perhaps when our app is working and more complete we can look at
converting additional portions of code into a more robust markup, but
for now I think it's totally adequate to just have the XML define
"doTheSpecialThingyYouKnowHowToDo" and have the code take it from
there. 

This allows us to at XML parse time determine which codepath we follow
so that we're not constantly checking for conditions that don't apply,
such as checking for the formation of the CGR in a game of 18EU.


> > I'd prefer not to hardcode this if we don't need to. 
> 
> Well, the below XML presumes the existence of code that
> understands what "ORperSR" means. No difference, I think,
> with what I have said. 
>  


By ORperSR i meant "how many ORs do we run before executing an SR".


> > >> 2. We seem to agree that there are three basic "types" of 
> > >> rounds: Auction, Stock, and Operating.
> > 
> > >Well, maybe one less, as I tend to agree with John David.
> > 
> > 
> > If we treat everything as a "round", we're able to do 
> > something like this:
> > 
> > <RoundOrder>
> > <AuctionRound>
> >    <numRounds="1">
> >    <blindAuction="false">
> > </AuctionRounds>
> > <StockRound>
> >    <StockMarketStyle="2D">
> >    <StockMarketType="1856">
> > </StockRound>
> > <OperatingRound>
> >    <ORperSR="1,2,3">
> >    <ORtriggers="3train,5train">
> > </OperatingRound>
> > <SomeSpecialRound>
> >    <SpecialRoundHappens="OR">
> >    <SpecialRoundCondition="PlayerDebtValue=nnn">
> >    <SpecialRoundAction="FormCNR"
> > </SomeSpecialRound>
> > </RoundOrder>
> 
> Good stuff, but this XML already presumes a lot of coding 
> on the top level to understand it!
> 
> My take:
> 
> <RoundOrder>
>   <Round type="Auction" class="game.1830.Auction" recurring="no"
> number="1"/>
>   <Round type="Stock" class="game.StockRound" recurring="yes" number="1">
>     <!-- XML specs for stockround to be put here. Will be parsed by SR
> class-->
>   </Round>
>   <Round type="Operating" class="game.OperatingRound" recurring="yes" 
>        number="1,2,3" numberIncreaseTrigger="3TRAIN,5TRAIN"
> timing="endOfStockRound">
>     <!-- XML specs for op.round here. Parsed by OR class -->
>   </Round>
>   <Round type="Special" class="game.1856.CGRFormation" recurring="no" 
>        number="0" triggerEvent="6TRAIN" timing="endOfOperatingTurn">
>     <!-- Perhaps more details, such as the new cert limits -->
>   </Round>
> </RoundOrder>
> 
> This assumes less knowledge at the top level on what types of round we have,
> and what parameters are relevant to each type.
> 
> The classes implementing each type of round would know what parameters are
> needed,
> and would be called to parse the inner XML (as I'm already doing in
> PublicCompany).
> 
> The "timing" attributes defer execution of the triggers until some
> additional
> event has happened (e.g. if a 3-train is bought, the NEXT set of OR's gets
> influenced;
> if in 1856 a 6-train is bought, the CGR is formed after the end of the
> company turn).
> 
> The Special round number="0" attribute excludes this special round from the
> normal flow.
> 


Perfect.  I hoped you'd take my approach a few steps further. I just
wanted to lay out the basic idea so that you could see I wasn't meaning
to hand-tune every detail of the game, but just enough that the code can
call into the proper classes. 

I think you've just about nailed the right amount of balance between the
assumptions the XML needs to make about the code executing it and where
we need to simply code a variety of classes to handle all the special
operations.


> > > Do all the classes that will implement some kind of round,
> > > subround or subsubround have something in common?
> > 
> > > I think at least one common method: nextAction,
> > > that the UI most call first after delivering each player action,
> > > so that it can be told which object's methods should be called 
> > > to get information about how to set up the screen
> > > and to enable/disable the player's next actions
> > > (as I already have described in some detail for the auctions).
> > 
> > > So I think we will also have an interface or base class named Round.
> > 
> > 
> > I think this whole problem is solved by using the sequence 
> > and configuration
> >  I've layed out above. 
> > 
> 
> Here I'm talking on the View/Model interface.
> How will the UI know that a new type of round is entered?
> 
> A different solution to that, and probably a better one that what I said
> first,
> is to have the UI always ask the GameManager what to do next.
> 

My thinking exactly. The UI should always be deferring to the
GameManager on what to display next. I fully expect that the "test" code
we've got in 18xx/test will eventually morph into the "real" code that
runs everything.

I suspect we'll probably have one parent window, two if I can figure out
a way to do it, that contains the Stock Market and the Hex Map. All
other windows will be children spawned from one of the parent windows.


> ---
> 
> I think we are making fine progress in clarifying our concepts.
> Now all the coding -- (oh yes: hardcoding takes less time!).
> 
> Erik.


I agree.



---Brett. 

People never lie so much as after a hunt, during a war, or before an
election. -- Otto Von Bismarck

RE: [Rails-devel] Initial Round

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

> >> 1. The turn order structure ought to be defined in XML 
> based on Game.
> >
> >Here we enter the difficult subject of what to put in the XML
> >and what in the code, and insofar we are putting stuff in the XML,
> >how and where we do that (e.g. see my earlier remarks on putting 
> >the player cash and certificate limits under <Bank>, as I did,
> >but unconvinced that that was the right way).
> 
> 
> To me, one of the problems we must solve is making our 
> application extensible by others.
> One way of doing that is to make a large amount of 
> configuration available outside the code.
> So, for me it makes sense to put as much as we can into the XML.
> 
> I think that, in the end, what we'll have is effectively an 
> 18xx markup language.
 
Given the ingenuity of 18xx game designers, I'm pretty sure that 
we will not very often be able to configure a new game by just writing XML.
Usually some code writing will be involved too.

Having said that, I agree with the general principle.
But I'm a bit wary of attempts to be dogmatic about it.

Complex procedures that, in all its details, are likely unique
can better be hardcoded. Such as CGR formation in 1856.
I'm not going to define that in XML!
Only where we find that other games do the same thing (perhaps with
small differences that can be parametrised) it makes sense
to generalise. 

We'll have to see where to find the balance.
 
> >Back to your point: I think we can safely hardcode the SR/OR sequence
> >(only the number of ORs needs be configured), and also the fact
> >that the first SR will always start with some kind of initial round.
> >The initial round will be contained in a configurable class, 
> >which encodes the procedure to be executed during that round.
> >I think we already have identified a common interface for that.
> 
> I'd prefer not to hardcode this if we don't need to. 

Well, the below XML presumes the existence of code that
understands what "ORperSR" means. No difference, I think,
with what I have said. 
 
> >> 2. We seem to agree that there are three basic "types" of 
> >> rounds: Auction, Stock, and Operating.
> 
> >Well, maybe one less, as I tend to agree with John David.
> 
> 
> If we treat everything as a "round", we're able to do 
> something like this:
> 
> <RoundOrder>
> <AuctionRound>
>    <numRounds="1">
>    <blindAuction="false">
> </AuctionRounds>
> <StockRound>
>    <StockMarketStyle="2D">
>    <StockMarketType="1856">
> </StockRound>
> <OperatingRound>
>    <ORperSR="1,2,3">
>    <ORtriggers="3train,5train">
> </OperatingRound>
> <SomeSpecialRound>
>    <SpecialRoundHappens="OR">
>    <SpecialRoundCondition="PlayerDebtValue=nnn">
>    <SpecialRoundAction="FormCNR"
> </SomeSpecialRound>
> </RoundOrder>

Good stuff, but this XML already presumes a lot of coding 
on the top level to understand it!

My take:

<RoundOrder>
  <Round type="Auction" class="game.1830.Auction" recurring="no"
number="1"/>
  <Round type="Stock" class="game.StockRound" recurring="yes" number="1">
    <!-- XML specs for stockround to be put here. Will be parsed by SR
class-->
  </Round>
  <Round type="Operating" class="game.OperatingRound" recurring="yes" 
       number="1,2,3" numberIncreaseTrigger="3TRAIN,5TRAIN"
timing="endOfStockRound">
    <!-- XML specs for op.round here. Parsed by OR class -->
  </Round>
  <Round type="Special" class="game.1856.CGRFormation" recurring="no" 
       number="0" triggerEvent="6TRAIN" timing="endOfOperatingTurn">
    <!-- Perhaps more details, such as the new cert limits -->
  </Round>
</RoundOrder>

This assumes less knowledge at the top level on what types of round we have,
and what parameters are relevant to each type.

The classes implementing each type of round would know what parameters are
needed,
and would be called to parse the inner XML (as I'm already doing in
PublicCompany).

The "timing" attributes defer execution of the triggers until some
additional
event has happened (e.g. if a 3-train is bought, the NEXT set of OR's gets
influenced;
if in 1856 a 6-train is bought, the CGR is formed after the end of the
company turn).

The Special round number="0" attribute excludes this special round from the
normal flow.

> > Do all the classes that will implement some kind of round,
> > subround or subsubround have something in common?
> 
> > I think at least one common method: nextAction,
> > that the UI most call first after delivering each player action,
> > so that it can be told which object's methods should be called 
> > to get information about how to set up the screen
> > and to enable/disable the player's next actions
> > (as I already have described in some detail for the auctions).
> 
> > So I think we will also have an interface or base class named Round.
> 
> 
> I think this whole problem is solved by using the sequence 
> and configuration
>  I've layed out above. 
> 

Here I'm talking on the View/Model interface.
How will the UI know that a new type of round is entered?

A different solution to that, and probably a better one that what I said
first,
is to have the UI always ask the GameManager what to do next.

---

I think we are making fine progress in clarifying our concepts.
Now all the coding -- (oh yes: hardcoding takes less time!).

Erik.

RE: [Rails-devel] Initial Round

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

>> Hmmmm...  I think this may be the goal for how it appears to 
>> the user. However, to keep things logically organized within 
>> the code, I think we'll need something that operates more like this:
>> 
>> 1. The turn order structure ought to be defined in XML based on Game.
>
>Here we enter the difficult subject of what to put in the XML
>and what in the code, and insofar we are putting stuff in the XML,
>how and where we do that (e.g. see my earlier remarks on putting 
>the player cash and certificate limits under <Bank>, as I did,
>but unconvinced that that was the right way).


To me, one of the problems we must solve is making our application extensible by others.
One way of doing that is to make a large amount of configuration available outside the code.
So, for me it makes sense to put as much as we can into the XML.

I think that, in the end, what we'll have is effectively an 18xx markup language.


>I must also warn that the XML parsing code already looks as if it 
>might become one of the bulkiest parts of the whole code, 
>and we haven't yet touched save and load.
>Iain's ComponentManager also imposes limitations (see below), 
>and I'm currently rethinking the way CompanyManager.xml is handled.


I expected this. As long as there are no technical limitations that we're going to run into, 
I think this is the right way to go.


>Back to your point: I think we can safely hardcode the SR/OR sequence
>(only the number of ORs needs be configured), and also the fact
>that the first SR will always start with some kind of initial round.
>The initial round will be contained in a configurable class, 
>which encodes the procedure to be executed during that round.
>I think we already have identified a common interface for that.


I'd prefer not to hardcode this if we don't need to. 


>> 2. We seem to agree that there are three basic "types" of 
>> rounds: Auction, Stock, and Operating.

>Well, maybe one less, as I tend to agree with John David.


If we treat everything as a "round", we're able to do something like this:

<RoundOrder>
<AuctionRound>
   <numRounds="1">
   <blindAuction="false">
</AuctionRounds>
<StockRound>
   <StockMarketStyle="2D">
   <StockMarketType="1856">
</StockRound>
<OperatingRound>
   <ORperSR="1,2,3">
   <ORtriggers="3train,5train">
</OperatingRound>
<SomeSpecialRound>
   <SpecialRoundHappens="OR">
   <SpecialRoundCondition="PlayerDebtValue=nnn">
   <SpecialRoundAction="FormCNR"
</SomeSpecialRound>
</RoundOrder>


Then we just iterate through the defined round order, decrementing any values of 
numRound, and not processing any rounds that have a numRounds value of 0.

We can code the GameManager to do the checking for any SpecialRounds that it needs 
to insert into the normal flow as well as whether the triggers have been hit to run more than 
one operating round between stock rounds.

We can even consider the end of the game a special round that is inserted into the normal 
rotation of stock and operating rounds.


>See above.
>And maybe a PlayerManager and Player.xml for the cert limits
>and the player cash (see above)?

I think we were probably needing these too.

>The existence of "Managers" seems to be determined largely by
>the requirements of the ComponentManager: each configurable
>component must have a singleton manager, and either a separate
>XML or its XML included in Game.xml.
>This strongly couples the top-level class setup to the XML setup, 
>and restricts both. Maybe that's the way to go, or maybe I am
>overlooking existing possibilities. Iain, any comments?


I agree, and I think it's not a bad way to go. Though, I'm not the expert here.


>If Game becomes a configurable component itself,
>we must look for a different class and XML file at the top
>(where it is lonely).


I don't think that'll be a huge problem to overcome.


>> I don't really expect there to be a new game that takes the 
>> round order _too_ far away from what most games currently do. 
>> However, it is entirely possible that someone comes up with a 
>> new sequence that we've yet to see. So, keeping each type of 
>> round seperated into their own classes is likely to be good 
>> for long-term managability.

> Definitely. 

> Do all the classes that will implement some kind of round,
> subround or subsubround have something in common?

> I think at least one common method: nextAction,
> that the UI most call first after delivering each player action,
> so that it can be told which object's methods should be called 
> to get information about how to set up the screen
> and to enable/disable the player's next actions
> (as I already have described in some detail for the auctions).

> So I think we will also have an interface or base class named Round.


I think this whole problem is solved by using the sequence and configuration
 I've layed out above. 

To me, it seems overly convoluted to talk about rounds and sub-rounds and 
sub-rounds of the sub-rounds. It's much easier to think of everything as a 
round; there are merely the two "standard" rounds: Stock and Operating, and 
there are special types of rounds, like Auctions, that interrupt the flow of 
alternating between stock and operating rounds.



---Brett.

RE: [Rails-devel] Initial Round

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

> Hmmmm...  I think this may be the goal for how it appears to 
> the user. However, to keep things logically organized within 
> the code, I think we'll need something that operates more like this:
> 
> 1. The turn order structure ought to be defined in XML based on Game.

Here we enter the difficult subject of what to put in the XML
and what in the code, and insofar we are putting stuff in the XML,
how and where we do that (e.g. see my earlier remarks on putting 
the player cash and certificate limits under <Bank>, as I did,
but unconvinced that that was the right way).

I must also warn that the XML parsing code already looks as if it 
might become one of the bulkiest parts of the whole code, 
and we haven't yet touched save and load.
Iain's ComponentManager also imposes limitations (see below), 
and I'm currently rethinking the way CompanyManager.xml is handled.

Back to your point: I think we can safely hardcode the SR/OR sequence
(only the number of ORs needs be configured), and also the fact
that the first SR will always start with some kind of initial round.
The initial round will be contained in a configurable class, 
which encodes the procedure to be executed during that round.
I think we already have identified a common interface for that.

> 2. We seem to agree that there are three basic "types" of 
> rounds: Auction, Stock, and Operating.

Well, maybe one less, as I tend to agree with John David.

> 3. A GameManager will use the XML game configuration to 
> establish the order in which they occur. I was planning this 
> sort of a layout when I made the stubs for the Game class. 
> Though, now it's looking like we'll probably want to make a 
> GameManager just like we have a CompanyManager and 
> ConfigurationManger and maybe even some appropriate 
> interfaces and abstracts.

See above.
And maybe a PlayerManager and Player.xml for the cert limits
and the player cash (see above)?

The existence of "Managers" seems to be determined largely by
the requirements of the ComponentManager: each configurable
component must have a singleton manager, and either a separate
XML or its XML included in Game.xml.
This strongly couples the top-level class setup to the XML setup, 
and restricts both. Maybe that's the way to go, or maybe I am
overlooking existing possibilities. Iain, any comments?

If Game becomes a configurable component itself,
we must look for a different class and XML file at the top
(where it is lonely).

> I don't really expect there to be a new game that takes the 
> round order _too_ far away from what most games currently do. 
> However, it is entirely possible that someone comes up with a 
> new sequence that we've yet to see. So, keeping each type of 
> round seperated into their own classes is likely to be good 
> for long-term managability.

Definitely. 

Do all the classes that will implement some kind of round,
subround or subsubround have something in common?

I think at least one common method: nextAction,
that the UI most call first after delivering each player action,
so that it can be told which object's methods should be called 
to get information about how to set up the screen
and to enable/disable the player's next actions
(as I already have described in some detail for the auctions).

So I think we will also have an interface or base class named Round.

<remainder snipped>

Erik.

RE: [Rails-devel] Initial Round

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

> Erik Vos wrote:
> > We have three round types: 
> > - initial round (buying privates),
> > - stock round,
> > - operation round.
> > (for now leaving aside specialties like the 18EU 
> > "Minor Company Final Exchange Round").
> 
> For most 18xx games, the initial auction (or starting packet 
> purchases) is
> not a separate kind of round, but happens during the first 
> stock round;
> and in fact, most games allow an operating round to occur 
> with some of the
> "starting packet" still unsold.  This will create several 
> problems if the
> initial round is a separate type of round:
> 
> *  You need to determine whether the next round is an 
> operating round or a
> stock round.
> 
> *  If the next round is an operating round, then after it you have to
> determine whether to go to another initial round or a stock round.

No big deal: just two flags. I agree, that from a structural point of 
view it looks better to classify auctions as subrounds of the stock round,
as well as nationalisations, the 18EU final exchange round, and
the 1841 4-train events can be seen subrounds of the operating round.

I was mainly concerned about how the code that builds the UI will
know that it has to prepare for an Auction. It looked easier to have it
start an auction right away, rather than let it start a Stock Round, 
which then needs to tell the UI "no, we'll have an Auction first."
But we may end up like this anyway, so your approach may be right
(see my other post, in which I adhere to your approach).

Brett, do you have a vision on the UI interfacing aspect?
 
> On the other hand, if the game starts with secretly written 
> bids (as 1841
> or 1853) these objections don't arise, and you do need a 
> separate initial
> round.

This is generally the case if the start packet must be sold out
in the initial round, for instance also in 18EU. 
But I would consider that just a boolean condition, rather than
that it would lead to a separate type of (sub)round. 
It is not even a separate variable, as the "mandatory completion" 
of this type of round directly follows from the procedure it embodies.

So I'd say: if some auctions go inside a SR, then all of them.
 
> So I say, yes, go ahead and define these three types of 
> rounds; but don't
> do anything in the "initial round" of games like 1830 or 1835 
> except to
> assign the seating order.  Instead, 1830 and 1835 
> start-packet turns take
> place in a stock round, and a global variable (perhaps 
> game_phase) should
> determine what actions are allowed during a stock-round turn.

I spoke about "buying privates", but many games sell minor companies
in the initial round, so "start packet" is the correct term indeed.
 
> For games like 1830 or 18EU, you'll want a fourth round type, > an
"auction
> round", to handle the auction of a particular private/minor.  
> This can be
> nested within a stock round, or you can start a new stock 
> round after it;
> but in either case the auction round doesn't move the 
> Priority Deal.  (I
> prefer the nested model because it makes the rounds in the 
> program agree
> with those in the rule book.)

I don't think 1830 is a good example, as all unsold privates are
auctioned at the same time. But indeed in 18EU each minor is
auctioned separately, so, following your hierarchical approach, 
we might call that a sub-subround.

Erik.

Re: [Rails-devel] Initial Round

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

Hmmmm...  I think this may be the goal for how it appears to the user. However, to keep things logically organized within the code, I think we'll need something that operates more like this:

1. The turn order structure ought to be defined in XML based on Game.
2. We seem to agree that there are three basic "types" of rounds: Auction, Stock, and Operating.
3. A GameManager will use the XML game configuration to establish the order in which they occur. I was planning this sort of a layout when I made the stubs for the Game class. Though, now it's looking like we'll probably want to make a GameManager just like we have a CompanyManager and ConfigurationManger and maybe even some appropriate interfaces and abstracts.

I don't really expect there to be a new game that takes the round order _too_ far away from what most games currently do. However, it is entirely possible that someone comes up with a new sequence that we've yet to see. So, keeping each type of round seperated into their own classes is likely to be good for long-term managability.

Speaking if queueing, this brings me to something Erik mentioned in a recent e-mail: The ability to undo.

This will probably necessitate a sort of queue or stack in which actions are stored historically as they happen from which we can simply recall the actions off the stack in the order they are placed upon the stack (or into the queue, whichever metaphor you like best).

It seems to me that if we're likely to do this for historical data, we could also do the same thing for queueing up what's scheduled to happen in the future, and simply use this as a part of how the GameManager I mention above deals with the situations already mentioned where the auction isn't a one-time thing.

Also, this would allow the GameManager to handle, and possibly predict, when things like the forming of the Canadian National Railway in 1856 need to happen. These sorts of special-case actions are probably going to be easier to code if we treat them as part of the round structure. I think that would minimize the amount of messy if-then checking in the operating round code.

This is good stuff. Keep the comments and ideas coming.

---Brett


-----Original Message-----
From: John David Galt <jd...@di...>
Sent: Apr 23, 2005 11:41 PM
To: rai...@li...
Subject: Re: [Rails-devel] Initial Round

Erik Vos wrote:
> We have three round types: 
> - initial round (buying privates),
> - stock round,
> - operation round.
> (for now leaving aside specialties like the 18EU 
> "Minor Company Final Exchange Round").

For most 18xx games, the initial auction (or starting packet purchases) is
not a separate kind of round, but happens during the first stock round;
and in fact, most games allow an operating round to occur with some of the
"starting packet" still unsold.  This will create several problems if the
initial round is a separate type of round:

*  You need to determine whether the next round is an operating round or a
stock round.

*  If the next round is an operating round, then after it you have to
determine whether to go to another initial round or a stock round.

On the other hand, if the game starts with secretly written bids (as 1841
or 1853) these objections don't arise, and you do need a separate initial
round.

So I say, yes, go ahead and define these three types of rounds; but don't
do anything in the "initial round" of games like 1830 or 1835 except to
assign the seating order.  Instead, 1830 and 1835 start-packet turns take
place in a stock round, and a global variable (perhaps game_phase) should
determine what actions are allowed during a stock-round turn.

For games like 1830 or 18EU, you'll want a fourth round type, an "auction
round", to handle the auction of a particular private/minor.  This can be
nested within a stock round, or you can start a new stock round after it;
but in either case the auction round doesn't move the Priority Deal.  (I
prefer the nested model because it makes the rounds in the program agree
with those in the rule book.)

Re: [Rails-devel] Initial Round

[John D. G. <jd...@di...>]

Erik Vos wrote:
> We have three round types: 
> - initial round (buying privates),
> - stock round,
> - operation round.
> (for now leaving aside specialties like the 18EU 
> "Minor Company Final Exchange Round").

For most 18xx games, the initial auction (or starting packet purchases) is
not a separate kind of round, but happens during the first stock round;
and in fact, most games allow an operating round to occur with some of the
"starting packet" still unsold.  This will create several problems if the
initial round is a separate type of round:

*  You need to determine whether the next round is an operating round or a
stock round.

*  If the next round is an operating round, then after it you have to
determine whether to go to another initial round or a stock round.

On the other hand, if the game starts with secretly written bids (as 1841
or 1853) these objections don't arise, and you do need a separate initial
round.

So I say, yes, go ahead and define these three types of rounds; but don't
do anything in the "initial round" of games like 1830 or 1835 except to
assign the seating order.  Instead, 1830 and 1835 start-packet turns take
place in a stock round, and a global variable (perhaps game_phase) should
determine what actions are allowed during a stock-round turn.

For games like 1830 or 18EU, you'll want a fourth round type, an "auction
round", to handle the auction of a particular private/minor.  This can be
nested within a stock round, or you can start a new stock round after it;
but in either case the auction round doesn't move the Priority Deal.  (I
prefer the nested model because it makes the rounds in the program agree
with those in the rule book.)

Re: [Rails-devel] Initial Round

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

On Sat, 2005-04-23 at 16:00 +0200, Erik Vos wrote:

> My proposal would be to create an interface (tentatively named Auction)
> which defines the following method sets:

I haven't played many of these games enough to know the auction
structure very well, so I'll need to defer most of this to you and
anyone else that wishes to contribute.

> Questions:
> 1. Does this make sense?

Yes. This is the right way to go, IMO.

> 3. Is anybody able to define not-overly-long descriptive class names
> for all these varieties? If not, I would simply call them AuctionLike1830,
> AuctionLike1841 etc.

You could simply go with Auction1830 or 1830Auction and omit the 'Like'.
That seems adequate to me.



---Brett. 

A conference is a gathering of important people who singly can do
nothing but together can decide that nothing can be done. -- Fred Allen

[Rails-devel] Initial Round

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

Although there is still a lot of work to to on the
classes developed so far (more features, Javadoc, 
toString(), save/restore) I can't resist the temptation
to look forward to what I think will be the next major 
step in adding functionality: the rounds.

We have three round types: 
- initial round (buying privates),
- stock round,
- operation round.
(for now leaving aside specialties like the 18EU 
"Minor Company Final Exchange Round").

For now I suppose that the Stock and Operation rounds can be handled 
by a single class each (stubs are already available), but the great variety
of initial round types may call for a whole range of different classes:

- 1830 auction
- 1835 standard (each time a limited set available at fixed price)
- 1835 Clemens (all available at a fixed price)
- 1837 (like 1835 standard, but with price reductions)
- 1841 standard (secret bids, revealed simultaneously)
- 1825/51 (shuffle and deal)
- 18EU (complex auction - IMO the most interesting subgame of them all)

and no doubt there are more different varieties.

The question I would like to discuss here is, if we can define a common
interface to all these classes, so that one common UI can possibly handle
all of these.

My proposal would be to create an interface (tentatively named Auction)
which defines the following method sets:

1. Methods that tell the UI what next moves are possible:
- which player has the turn
- what privates are available for immediate buying, and at what price,
- what privates are available for bidding, and at what minimum price,
- whether passing is allowed or not,
- which privates are available to select for the next auction (18EU).
The UI should call these methods to find how to reconfigure
the screen for the next player action.

2. Methods that tell the Auction-implementing class what action the player
has performed.
This action will then be executed, after which a next set of options is
prepared.

This way I think we can handle all of the above cases.
About the more esoteric ones:
- Shuffle and deal: each player is offered only one option, and may not
pass.
- Secret bidding: players can enter bids in any sequence, when all have
passed
all the bids are processed and the results made available.

Questions:
1. Does this make sense?
2. Did I overlook important initial round mechanisms that should also be
considered?
3. Is anybody able to define not-overly-long descriptive class names
for all these varieties? If not, I would simply call them AuctionLike1830,
AuctionLike1841 etc.

Erik.

RE: [Rails-devel] Fully Working Stock Tokens

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

>> I've just committed the rest of the UI code to display stock 
>> tokens moving around the stock market.
>> 
>> You can click on the company name to select the token, and 
>> use the buttons to push them all over the board.

>Yes! It works for me.

>One small gripe: if the stockmarket window gets overlaid by another
>window, and then gets focus again, the stockmarket does not repaint,
>except the markers (chits) and there immediate surroundings.

I know.

I need to add WindowListener events.  I'll be doing that soon.


>I have done the colour change: in CompanyManager.xml all colours 
>are now given as hex values. PublicCompanyI.get[F|B]gColour()
>now returns a Color object. I have added also getHex[F|B]gColour()
>methods that return the colour as a hex value (String) for my servlets.

This is awesome! Thanks!


>I hope the commit has worked - I'm now trying to do that from
>Eclipse (I have just upgraded to 3.0), but it is less clear what
>is going on there than it was with Tortoise (which BTW does not work
>anymore as it now has started using :extssh:, which is what I
>specified for Eclipse - Sourceforge does not accept that?)
>How do you commit? It's all very confusing.

Yup. The commit worked. I have the new code.

I use Fedora Core 3 at home, so I just use the command-line cvs.
At work I've been using Eclipse's built-in CVS access.

I just started out by adding the project from cvs, and then commits and updates work with no problem.
 

>One thought I had is to have Company and Player displays
>not unlike those in the bottom half of my servlet output 
>(see e.g. http://home.hccnet.nl/erik.vos/18xx/gametest5.html).
>In these tables, those fields where some action could be performed
>should be highlighted and made clickable (perhaps turn into buttons).

Buttons aren't necessary. I can continue doing the same thing as I have with making the company name clickable.

I've been taking quite a few cues from your screenshots. :-)  

>Just a thought. Designing user interfaces is not one of my strengths....

Good ideas. Lemme roll 'em around in my head a while.

> Oh yes, and we need an Undo button!

I agree. Though, that means tracking actions so that we have something to undo.


----Brett

RE: [Rails-devel] Fully Working Stock Tokens

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

> I've just committed the rest of the UI code to display stock 
> tokens moving around the stock market.
> 
> You can click on the company name to select the token, and 
> use the buttons to push them all over the board.

Yes! It works for me.

One small gripe: if the stockmarket window gets overlaid by another
window, and then gets focus again, the stockmarket does not repaint,
except the markers (chits) and there immediate surroundings.


I have done the colour change: in CompanyManager.xml all colours 
are now given as hex values. PublicCompanyI.get[F|B]gColour()
now returns a Color object. I have added also getHex[F|B]gColour()
methods that return the colour as a hex value (String) for my servlets.

ui.StockChart has been changed to pick up the Color objects - 
no more need for stringToColor().

I hope the commit has worked - I'm now trying to do that from
Eclipse (I have just upgraded to 3.0), but it is less clear what
is going on there than it was with Tortoise (which BTW does not work
anymore as it now has started using :extssh:, which is what I
specified for Eclipse - Sourceforge does not accept that?)
How do you commit? It's all very confusing.
 
> There is a bug with the message box that displays if no token 
> is selected: the error message doesn't show up in the box. I 
> haven't tracked that bug down, but I suspect that it's likely 
> due to the brute force nature of the current UI code.
> 
> Either way, I think now is the time to start looking at the 
> UI and figuring out how we want to display the various bits 
> of information. I suppose that until we get some volunteers 
> for creating game artwork, or permission to use existing art 
> from the existing games, we can stick with raw numeric 
> output. However, I think it might be worthwhile to eventually 
> display stock certificates graphically and perhaps aim for a 
> drag-n-drop UI.

> Thoughts?

One thought I had is to have Company and Player displays
not unlike those in the bottom half of my servlet output 
(see e.g. http://home.hccnet.nl/erik.vos/18xx/gametest5.html).
In these tables, those fields where some action could be performed
should be highlighted and made clickable (perhaps turn into buttons).

In an SR the player name that has the turn could be highlighted,
and all the share percentages that he could change should become clickable.
For instance, to buy a B&O from IPO Iain should click on the 40%
number on the B&O row, IPO column. To sell a B&O share click on his 
company cell in the Player area, showing P50.
Clicking meaning: "get one away from there".

This avoids the need to have buttons all around.

Just a thought. Designing user interfaces is not one of my strengths....

Oh yes, and we need an Undo button!

Erik.