rails-devel

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] 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...>]

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

[<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

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

Ok...  Done.   .classpath is removed.

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

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.

RE: [Rails-devel] The Player Class

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

>> Is there ever a StartPacket that isn't an Auction of some sort?

>Depends on whether or not "Auction" implies bidding in your definition.
>In 1835 there is no bidding, just buying or passing.

That's easy enough. It's an auction where the bid values are set and unchangable.
Perhaps that means that it's an even more "basic" auction than the 1830-style auction
and 1830's Auction should inherit from 1835's Auction and just be extended to allow 
changable bids.

My viewpoint in this area is focused on maximizing the amount of code reuse to 
minimize the amount of effort needed to support the long list of 18xx games.

>I've no problem with a wide interpretation of the term auction, 
>but John David has objected against that.

>I don't find the bidding/non-bidding aspect particularly important.
>18EU has a fairly complex mix of bidding and non-bidding turns.


No disrespect directed at Mr. Galt, but he hasn't contributed anything but opinion so far. 
A few of his comments lead me to suspect that he hasn't even checked any current 
versions of the code out of CVS.

To be perfectly honest, until these factors change, I'm more inclined to favor 
your analysis and opinions over his. We currently seem to agree about the details 
of implementing the Auctions, so I'm in favor of doing it our way.

Just in case there was ever any doubt, I'm happy to spell it out explicitly: This 
project is a meritocracy. Your vote in what happens to this project is exactly 
the size of your contributions of code, art, documentation, etc. Opinions given 
without other contributions will be considered, but won't carry the same weight 
as the opinions of regular contributors.

 
> Not sure if the special rounds have enough in common to give
> "SpecialRound" any substance.

I think the single thing that'll give it substance is the inheritable property 
of when the event fires off in the round or turn order.

> But I fully agree with the Round interface. 
> Meaning: a process that consists of multiple "turns".

Great.  If you want, I'll leave the initial definitions up to you, as I'm 
focusing on bringing the UI up to speed with your servlet. I think 
we've already covered the initial definition. 

>Very good to hear that. 
>I've already noticed an increased level of activity on your side....

> As for me, I have a full-time job and a family life, 
> so most of my coding efforts will remain restricted to weekends.
> But next week I'm free and mostly at home, so who knows....

No worries.

I just happen to be lucky enough to have recently gotten myself a job 
that allows me to write code in between all my other daily tasks.


---Brett

RE: [Rails-devel] The Player Class

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

> Great.  If you want, I'll leave the initial definitions up to 
> you, as I'm 
> focusing on bringing the UI up to speed with your servlet. I think 
> we've already covered the initial definition. 

OK, I will try to continue doing that.

Erik.

Re: [Rails-devel] The Player Class

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

wak...@ea... wrote:
> No disrespect directed at Mr. Galt, but he hasn't contributed anything but opinion so far. 
> A few of his comments lead me to suspect that he hasn't even checked any current 
> versions of the code out of CVS.

I've been unable to find the code.  The project directory is empty.

RE: [Rails-devel] The Player Class

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

Oh hell.

Yeah, I want to be compatible with 1.4 because 1.5 really hasn't gotten much market penetration yet.

However, I'm using 1.5 on all my machines. That explains it.

I suppose we just have Options extend from both JFrame and JComponent then.

---Brett.

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


> These conversions to static methods broke a whole bunch of 
> things, but I
> think I've cleaned them all up, so the current code in CVS ought to
> build and run without errors.

Unfortunately this still does not apply to Options.

I may now have found why: this reference
http://java.sun.com/j2se/1.5.0/docs/guide/swing/1.5/
explains with that Java 1.5 setPreferredSize() has been
promoted from class JComponent to Component.

Now Component is in the class hierarchy of JFrame
(the base class of Options), but JComponent is not.
So that is why setPreferredSize does not compile with my Java 1.4.2.

So either this method can't be used, or we must change to Java 1.5
as the agreed platform (I thought it was 1.4).

Erik.

RE: [Rails-devel] The Player Class

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

> Oh hell.
> 
> Yeah, I want to be compatible with 1.4 because 1.5 really 
> hasn't gotten much market penetration yet.
> 
> However, I'm using 1.5 on all my machines. That explains it.
> 
> I suppose we just have Options extend from both JFrame and 
> JComponent then.

Not sure what that would mean.

I have checked in a version of Options that works for me.
I've changed 5 lines, each indicated by a comment.
Now I can finally run your GameTest!
Please have a look if this works and is acceptable to you.

The removal of setPreferredSize() made it compile,
but run-time errors told me to insert getContentPane() in 4 more lines.

Erik.

Re: [Rails-devel] The Player Class

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

>I've been unable to find the code.  The project directory is empty.

You'll need to go to the sourceforge project page: http://www.sourceforge.net/projects/rails

Then, you'll need to check it out from CVS. Sourceforge has decent directions on this:  http://sourceforge.net/cvs/?group_id=132173

Don't try using http://rails.sf.net, it won't work until we create an actual project website.

RE: [Rails-devel] The Player Class

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

Wait... that won't work.

Java doesn't do multiple inheritance.

Damn.

I guess this is why they moved this method around between the versions.

Ok... I'll use setSize() instead of setPreferredSize(). setSize() comes from Component in 1.4

---Brett.

-----Original Message-----
From: wak...@ea...
Sent: Apr 28, 2005 3:17 PM
To: rai...@li...
Subject: RE: [Rails-devel] The Player Class

Oh hell.

Yeah, I want to be compatible with 1.4 because 1.5 really hasn't gotten much market penetration yet.

However, I'm using 1.5 on all my machines. That explains it.

I suppose we just have Options extend from both JFrame and JComponent then.

---Brett.

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


> These conversions to static methods broke a whole bunch of 
> things, but I
> think I've cleaned them all up, so the current code in CVS ought to
> build and run without errors.

Unfortunately this still does not apply to Options.

I may now have found why: this reference
http://java.sun.com/j2se/1.5.0/docs/guide/swing/1.5/
explains with that Java 1.5 setPreferredSize() has been
promoted from class JComponent to Component.

Now Component is in the class hierarchy of JFrame
(the base class of Options), but JComponent is not.
So that is why setPreferredSize does not compile with my Java 1.4.2.

So either this method can't be used, or we must change to Java 1.5
as the agreed platform (I thought it was 1.4).

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

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

It's ugly, but if it compiles, that's all I care about right now.

I suspect we'll have to remove setPreferredSize from the rest of the UI too.

---Brett.


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


Not sure what that would mean.

I have checked in a version of Options that works for me.
I've changed 5 lines, each indicated by a comment.
Now I can finally run your GameTest!
Please have a look if this works and is acceptable to you.

The removal of setPreferredSize() made it compile,
but run-time errors told me to insert getContentPane() in 4 more lines.

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...>]

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

It could be, sure. 
It's now a singleton, though not very well managed.
 
> >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

I see. 


> 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.

It already *was* used for storing a single player's data!
I suppose you meant: "so that it ONLY can be used for....".

That restriction now forced me to create and store the player list in my
servlet too.

In hindsight, I think the player list belongs in Game
(not in Player or in GameLoader),
so that all possible UIs can get it from there.
What about that?

We should be careful to keep game data and UI stuff separate,
so that in the future our classes can also be used for
a 18xx game server (just to name one possibility).
So the player list should not be saved in the UI code.


On Game: I was thinking that we could rework Game into a singleton
class just like CompanyManager and StockMarket, and also
created by ComponentManager, in which certain game-wide
properties could be initialised from XML that would not
fit easily elsewhere. E.g. the definitions regarding "rounds",
the size of the Bank etc.

But the players will have to come from the UI - any UI!

And maybe Game and GameLoader should swap names.
 
> Things are starting to look a lot like an actual game. It's 
> quite encouraging.

If you can fix that missing-method compiler error in Options,
it might for me too.....

Erik.

RE: [Rails-devel] The Player Class

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

On Wed, 2005-04-27 at 00:38 +0200, Erik Vos wrote:
> > Though, now that I think about it, perhaps Bank should be a 
> > totally static 
> > class?
> 
> It could be, sure. 
> It's now a singleton, though not very well managed.
>  

It just seems like this is one of the rare instances that I can not
envision needing more than one of these.


> In hindsight, I think the player list belongs in Game
> (not in Player or in GameLoader),
> so that all possible UIs can get it from there.
> What about that?
> 
> We should be careful to keep game data and UI stuff separate,
> so that in the future our classes can also be used for
> a 18xx game server (just to name one possibility).
> So the player list should not be saved in the UI code.
> 


I was seeing the same thing myself. Probably most or all of GameLoader
can be moved into Game.

> 
> On Game: I was thinking that we could rework Game into a singleton
> class just like CompanyManager and StockMarket, and also
> created by ComponentManager, in which certain game-wide
> properties could be initialised from XML that would not
> fit easily elsewhere. E.g. the definitions regarding "rounds",
> the size of the Bank etc.
> 
> But the players will have to come from the UI - any UI!
> 
> And maybe Game and GameLoader should swap names.
>  

Yes, yes, and probably yes.


> > Things are starting to look a lot like an actual game. It's 
> > quite encouraging.
> 
> If you can fix that missing-method compiler error in Options,
> it might for me too.....
> 

That is a really bizarre error. The setPreferredSize method ought to be
inherited from JComponent.

http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/JComponent.html#setPreferredSize(java.awt.Dimension)

Unless "import java.awt.*" is missing from the file, I can only think
that you've got a bad copy of the file.

I just did a clean checkout of the whole project, and it compiles and
runs just fine for me.


---Brett. 

Barbie says, Take quaaludes in gin and go to a disco right away! But Ken
says, WOO-WOO!! No credit at "Mr. Liquor"!!

RE: [Rails-devel] The Player Class

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

> > > Though, now that I think about it, perhaps Bank should be a 
> > > totally static 
> > > class?
> > 
> > It could be, sure. 
> > It's now a singleton, though not very well managed.
> >  
> 
> It just seems like this is one of the rare instances that I can not
> envision needing more than one of these.

That is why it is a singleton - exactly one instance.
Of course, often singletons can as well be "zerotons" 
- just class (static) methods, as you propose.
This is OK if subclassing is not an issue.
But if we have to count with "extended" Bank functionality in
a possible future subclass, a singleton is better.

Erik. 

RE: [Rails-devel] The Player Class

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

> > In hindsight, I think the player list belongs in Game
> > (not in Player or in GameLoader),
> > so that all possible UIs can get it from there.
> > What about that?
> > 
> > We should be careful to keep game data and UI stuff separate,
> > so that in the future our classes can also be used for
> > a 18xx game server (just to name one possibility).
> > So the player list should not be saved in the UI code.
> > 
> 
> 
> I was seeing the same thing myself. Probably most or all of GameLoader
> can be moved into Game.

Except the part that calls the UI methods.
If you want I can work on that next weekend or next week,
when I should have some time. I could also make a start 
with "turn management".

Which brings me back to the old question how to define
the View/Model interface. Last week I've already tried to
describe the Auction (renamed to StartPacket) part of that.

I consider the Model to be a state machine, which changes its own
state as a consequence of player actions, passed via the UI.

The general scenario that I have in mind for interactions 
across that boundary runs like the following
(with "current Model process" I mean the round or subround or 
other distinguishable process that the game is currently in,
which I suppose is represented by some Model class instance):

forever {
   Player: Executes some action.
   View (UI): Catches the action and interprets it.
       Call appropriate methods in the current Model process.
   Model: Logs the action, and processes it, updating the Model state.
       If the current Model process termininates (e.g., a Stock Round is
over),
       or if some subprocess needs be started (e.g., an auction)
       it notifies a central controller (let's call it GameManager) about
that,
       before returning to the UI.
   View: Calls the GameManager to find what the current Model process is
       (it might have changed, as indicated above).
       Then it calls the (old or new) current Model process and any other
Model class
       to find out: (1) what UI and data to display, (2) who's turn it is, 
       (3) what actions are allowed.
       The UI rebuilds the screen accordingly.
}

This is a rather loose description that probably needs refinement.

BTW one reason that I intend to continue developing my test servlet is
exactly to ensure, that we create a proper View/Model boundary.
If our code works both ways, we're probably OK.
And it also frees me from being totally dependent on the progress of UI
development.
(I have ordered some Swing books, though!)

Erik.

RE: [Rails-devel] The Player Class

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

On Wed, 2005-04-27 at 23:59 +0200, Erik Vos wrote:
> > > In hindsight, I think the player list belongs in Game
> > > (not in Player or in GameLoader),
> > > so that all possible UIs can get it from there.
> > > What about that?
> > > 
> > > We should be careful to keep game data and UI stuff separate,
> > > so that in the future our classes can also be used for
> > > a 18xx game server (just to name one possibility).
> > > So the player list should not be saved in the UI code.
> > > 
> > 
> > 
> > I was seeing the same thing myself. Probably most or all of GameLoader
> > can be moved into Game.
> 
> Except the part that calls the UI methods.
> If you want I can work on that next weekend or next week,
> when I should have some time. I could also make a start 
> with "turn management".
> 

I cleaned up the code I already had in GameLoader today. I've renamed it
to GameUILoader to make its purpose more clear.

I also have changed quite a bit of Game and Bank to static methods. I
agree with you that Bank may or may not need to be a singleton at some
point. Though, I can't really imagine the mechanics for an instance
where we'd have more than one bank, especially because breaking the bank
is such an integral part of the end game.

These conversions to static methods broke a whole bunch of things, but I
think I've cleaned them all up, so the current code in CVS ought to
build and run without errors.


> Which brings me back to the old question how to define
> the View/Model interface. Last week I've already tried to
> describe the Auction (renamed to StartPacket) part of that.
> 


Is there ever a StartPacket that isn't an Auction of some sort?

How about we do this:

Let's define an interface called Round.
Then we define three more interfaces called StockRound, OperatingRound,
and SpecialRound that all extend from Round.
Lastly, let's have Auction be an interface extended from SpecialRound.

>From there, we'll create our actual Auction types, like 1830Auction,
etc. I think that if we implement the auctions one type at a time
starting with the most basic, we can do some analysis about similarities
to other auctions that will allow us to create a hierarchy that moves
from most basic to most complex, inheriting similarities from one
Auction to the next and overriding previous implementations where
differences crop up.

If there are any non-Auction starting rounds, they too can just extend
from SpecialRound, just like any other special-case sub-rounds, such as
forming the CGR in 1856.

In my opinion, this takes advantage of one of the best parts of being
object-oriented in the first place: Code Reuse. This is a big enough
project that if we can find areas where we only need to code certain
behavior once and allow everything that needs said behavior to inherit
it, we really ought to.


> I consider the Model to be a state machine, which changes its own
> state as a consequence of player actions, passed via the UI.
> 


Agreed.


> The general scenario that I have in mind for interactions 
> across that boundary runs like the following
> (with "current Model process" I mean the round or subround or 
> other distinguishable process that the game is currently in,
> which I suppose is represented by some Model class instance):
> 
> forever {
>    Player: Executes some action.
>    View (UI): Catches the action and interprets it.
>        Call appropriate methods in the current Model process.
>    Model: Logs the action, and processes it, updating the Model state.
>        If the current Model process termininates (e.g., a Stock Round is
> over),
>        or if some subprocess needs be started (e.g., an auction)
>        it notifies a central controller (let's call it GameManager) about
> that,
>        before returning to the UI.
>    View: Calls the GameManager to find what the current Model process is
>        (it might have changed, as indicated above).
>        Then it calls the (old or new) current Model process and any other
> Model class
>        to find out: (1) what UI and data to display, (2) who's turn it is, 
>        (3) what actions are allowed.
>        The UI rebuilds the screen accordingly.
> }
> 


Exactly as I see it, and exactly as we've been implementing it so far.


> This is a rather loose description that probably needs refinement.
> 
> BTW one reason that I intend to continue developing my test servlet is
> exactly to ensure, that we create a proper View/Model boundary.
> If our code works both ways, we're probably OK.
> And it also frees me from being totally dependent on the progress of UI
> development.
> (I have ordered some Swing books, though!)

Totally fine by me. Hell, if this project ends up having a couple
different ways of providing users the ability to play 18xx games, I
won't complain.

It looks like I'm going to have a pretty fair amount of time to commit
to this project each day now that some things in my personal life have
stabilised again.

I expect I'll be ordering those Swing books soon as well. Though, there
is enough documentation on-line that seems to be handling my current
needs.



---Brett. 

A little experience often upsets a lot of theory.

RE: [Rails-devel] The Player Class

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

> Is there ever a StartPacket that isn't an Auction of some sort?

Depends on whether or not "Auction" implies bidding in your definition.
In 1835 there is no bidding, just buying or passing.

I've no problem with a wide interpretation of the term auction, 
but John David has objected against that.

I don't find the bidding/non-bidding aspect particularly important.
18EU has a fairly complex mix of bidding and non-bidding turns.
 
> Let's define an interface called Round.
> Then we define three more interfaces called StockRound, 
> OperatingRound,
> and SpecialRound that all extend from Round.
> Lastly, let's have Auction be an interface extended from SpecialRound.

Not sure if the special rounds have enough in common to give
"SpecialRound" any substance.

But I fully agree with the Round interface. 
Meaning: a process that consists of multiple "turns".

<much snipped, with which I generally agree>.
 
> It looks like I'm going to have a pretty fair amount of time to commit
> to this project each day now that some things in my personal life have
> stabilised again.

Very good to hear that. 
I've already noticed an increased level of activity on your side....

As for me, I have a full-time job and a family life, 
so most of my coding efforts will remain restricted to weekends.
But next week I'm free and mostly at home, so who knows....

Erik.

RE: [Rails-devel] The Player Class

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

> These conversions to static methods broke a whole bunch of 
> things, but I
> think I've cleaned them all up, so the current code in CVS ought to
> build and run without errors.

Unfortunately this still does not apply to Options.

I may now have found why: this reference
http://java.sun.com/j2se/1.5.0/docs/guide/swing/1.5/
explains with that Java 1.5 setPreferredSize() has been
promoted from class JComponent to Component.

Now Component is in the class hierarchy of JFrame
(the base class of Options), but JComponent is not.
So that is why setPreferredSize does not compile with my Java 1.4.2.

So either this method can't be used, or we must change to Java 1.5
as the agreed platform (I thought it was 1.4).

Erik.