rails-devel — List for discussion of Rails development

[Rails-devel] Bug: Starting a company at $100

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

It looks like we're doing a little extra subtraction when a company starts its par value at 100$

The money transfer is correct for 90$ and 67$ (and by logical induction, every value except 100$). However, for the 100$ start price we're taking 300$ away from the player and giving it to the company's treasury.

Can someone track down this bug?  I can't seem to locate it.


---Brett.

[Rails-devel] RE: Stock Round

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

The basic StockRound class now seems to work.
I have changed GameTestServlet to use it, and it looks good.

I have added error messages, which are saved in Log,
that now has a separate buffer for such messages.
The error messages can be displayed on screen, 
but are not be logged.
I display the errors in red (and the log messages in black).

I see StockRound and its future siblings as the main
components in the middle layer, between the UI and
the data objects. Game/GameManager also reside there.

Quite some parameters are still hardcoded the 1830 way, 
such as floating when 60% is sold, full capitalisation etc.
Much additional XML work is needed to configure all that, 
but maybe it is more useful now to get on with the implementation
of the various rounds, as these are the backbone of the whole game.

There isn't a StockRoundI interface yet, but I suppose we will need that too
to facilitate future extension.

Erik.

[Rails-devel] Stock Round

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

I have checked in the initial versions of Round and StockRound. 
To support these, some methods have been added to other classes too.

The only thing I have checked is that all this compiles.
I have not used this new stuff anywhere yet.
I will try to do that in the coming days. 

Brett, I don't recommend to try using this in your code
until I have done some real testing. I'm only publishing this
stuff now to give you a sense of what I'm doing.
Quite untypical for me, most of the javadoc is there, 
as well as a lot of comments.

As discussed before, there are two groups of methods:

- a set of methods that processes player actions. 
The intention is to have all stock round actions be done 
via this class (I know this duplicates earlier work,
but currently think this is the best way to do it). 
All methods return false if the action is illegal
(maybe I should provide error messages, or throw an
Exception - suggestions welcome).

- a set of methods that tell the UI what the status is,
who has the turn, and what shares can be bought or sold,
taking into account *all* rules. (That "all" I have not 
realised yet, of course, but that is the intention.
There are a lot of TODO's).

For each Stock Round, a new instance must be created
(GameManager should do that).
Permanent memory (Priority Deal) is through static attributes.

So far it looks nice and right to me, but as you know the proof 
of the pudding is in the eating....

Erik.

RE: [Rails-devel] Stocks or Certificates?

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

> >As for its attributes, I'm considering to replace "share" (the
> >percentage of ownership) by "shares" (the number of shares).
> >I've already added an attribute "shareUnit" to PublicCompany
> >(which is the percentage of ownership of "one share").
> >Of course: "share" = "shares" * "shareUnit".
> 
> Good call.  This is much more scalable.

OK, done that.
The CompanyMamager.xml files have also been updated.

Certificate now has 2 share-getters:
getShares(), which gives the value of "shares" defined above, and
getShare(), which returns shares * shareUnit.

It works for me, but could not check your version.
Please check correct display of the share values!

Erik.

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

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

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

>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

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

> 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

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

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] Stocks or Certificates?

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

>> It looks like Certificate is being used in the PublicCompany 
>> class, among others. Is there any reason I should not just 
>> remove the Stock class?

> Please do.

Done.

> When creating Certificate I did in fact overlook the existence
> of Stock. I chose the name 'Certificate' deliberately to emphasize 
> its meaning in view of the explicit distinction between "Share"
> and "Certificate" that all 18xx games make.

No worries. Stock just had a bunch of stubs I'd created.

The only problem was that Player was originally referencing those stubs for the buyShare and sellShare methods.

I've fixed those to now reference Certificates instead. Also, they're no longer stubs, but actually working methods. :-D

I've also created a PlayerManager to hold methods that don't really quite fit into the Player class itself, such as getPlayerByName().  It's not quite the same sort of singleton that the other managers are, but it uses many of the same conventions for the sake of consistency.

>As for its attributes, I'm considering to replace "share" (the
>percentage of ownership) by "shares" (the number of shares).
>I've already added an attribute "shareUnit" to PublicCompany
>(which is the percentage of ownership of "one share").
>Of course: "share" = "shares" * "shareUnit".

Good call.  This is much more scalable.


---Brett

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] Stocks or Certificates?

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

> It looks like we've got a bit of duplication of code.
> 
> There's a Stock class and there's a Certificate class.
> 
> Other than the obvious difference in keystrokes, is there any 
> reason why they should both exist?
> 
> It looks like Certificate is being used in the PublicCompany 
> class, among others. Is there any reason I should not just 
> remove the Stock class?

Please do.

When creating Certificate I did in fact overlook the existence
of Stock. I chose the name 'Certificate' deliberately to emphasize 
its meaning in view of the explicit distinction between "Share"
and "Certificate" that all 18xx games make.

As for its attributes, I'm considering to replace "share" (the
percentage of ownership) by "shares" (the number of shares).
I've already added an attribute "shareUnit" to PublicCompany
(which is the percentage of ownership of "one share").
Of course: "share" = "shares" * "shareUnit".

The reason is to facilitate the change of the percentage
of ownership that one share represents, as happens in many games.

For instance, in 1826 many companies start as a 5-share company,
where the President's share represents 40% (2 shares of 20% each).
Later 5 additional shares are issued, the President's share then 
becomes 20% (2 shares of 10%). So only the share unit changes.

In 1856, the CGR share unit can be either 10% or 5%.

Erik.

[Rails-devel] Stocks or Certificates?

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

It looks like we've got a bit of duplication of code.

There's a Stock class and there's a Certificate class.

Other than the obvious difference in keystrokes, is there any reason why they should both exist?

It looks like Certificate is being used in the PublicCompany class, among others. Is there any reason I should not just remove the Stock class?

---Brett.

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

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

[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

[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.
 
> >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] Selecting a game

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

Hmmm... that'll work for now. 

Though, in the future, I think I'd like some sort of configuration validity checking so that we're not displaying non-working games. However, this isn't a high priority.


---Brett

-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Apr 26, 2005 11:38 AM
To: rai...@li...
Subject: RE: [Rails-devel] Selecting a game

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




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

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

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

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

???

This has nothing to do with an array (or list, or collection)
being declared static. You only should not dimension it with
a final static constant.

That is why I do not use an array but an ArrayList,
which has no predefined limit.

Erik.