rails-devel — List for discussion of Rails development

Re: [Rails-devel] Log4j logging

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

> > There is a new properties file called "my.properties",
> > which is intended to hold the user's local preferences
> > (in so far these are not configurable by some screen).
> > Currently this file only holds the SVG/GIF tile preference,
> > and the log4j properties.
> > One of the log4j properties is the log file path; the
> > default is log/18xx.log.
> >
> 
> We should include a "remember my choices" style of checkbox or button
> and save more of the UI fields into the properties file. This should
> be in the Options UI and one of the drop-downs so the user can do it
> both before starting a game and during a game.

Do we already have any choice items like that?
I don't think so, but once we have such items, 
we should find a place to store these.

I don't know how such storage is realised in other systems.
If it's a properties file, I would suggest to create 
another one for that purpose: one that can be overwritten
by the program after any change.
my.properties would then be reserved for properties 
that are not (or not yet) maintainable via the UI.

However, I don't have any strong feelings about this.

BTW by default log4j expects a configuration file named
log4j.properties, but I have changed this into my.properties
by setting a system property in the main() method.
This property is checked by log4j. It can also be provided 
on the command line, but I don't check that yet.
This property setting should always be the first statement to execute
in any new main program that we might develop in the future. 

Erik.

Re: [Rails-devel] Log4j logging

[brett l. <wak...@gm...>]

On 1/12/07, Erik Vos <eri...@hc...> wrote:
> I have implemented log4j logging throughout.
> Most System.out.println() statements have been replaced by log.debug().

Excellent!

> There is a new properties file called "my.properties",
> which is intended to hold the user's local preferences
> (in so far these are not configurable by some screen).
> Currently this file only holds the SVG/GIF tile preference,
> and the log4j properties.
> One of the log4j properties is the log file path; the
> default is log/18xx.log.
>

We should include a "remember my choices" style of checkbox or button
and save more of the UI fields into the properties file. This should
be in the Options UI and one of the drop-downs so the user can do it
both before starting a game and during a game.


---Brett.

[Rails-devel] Log4j logging

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

I have implemented log4j logging throughout.
Most System.out.println() statements have been replaced by log.debug().

There are two "appenders" (i.e. log message destinations):
the console and a daily rolling log file.

The log file logs everything and includes time stamps and other details.
The console does not get "debug"-level messages and has less detail.

To avoid confusion, I have renamed the Log Window to Report Window,
because it holds what can best be described as the game report
(I would like to add Print and Save buttons to this window).
The lines added to this window are also logged (level INFO), 
as well as all messages sent to the UI.

There is a new properties file called "my.properties",
which is intended to hold the user's local preferences
(in so far these are not configurable by some screen).
Currently this file only holds the SVG/GIF tile preference,
and the log4j properties.
One of the log4j properties is the log file path; the
default is log/18xx.log. 

The new class util.Config reads my.properties into a Properties map.
Any class can retrieve any property with the Config.get() method.
Other property files can easily be added.

I have changed ImageLoader to use the GIF/SVG preference.
If the preferred type (SVG is default) is not found, the
other type is looked for. This class was also changed
to consistently use Util.getStreamForFile(). 
This method looks first at the file system and, if a tile 
(or whatever else - it is also used to find XML files)
is not found there, into the Rails jar (incl. version number).

Jar file log4j-1.2.14.jar has been added to the lib directory
and must be added to the project's build path.

Comments welcome, as usual.

Erik Vos

Re: [Rails-devel] Logging

[brett l. <wak...@gm...>]

On 1/12/07, Erik Vos <eri...@hc...> wrote:
>
> Loggers (in the log4j sense) do not relate to different log files,
> but to the granularity with which log levels can be set to
> different values for different parts of the code.
>
> For instance, if we would define a logger for each package,
> we could set the log level to DEBUG for the ui package whilst leaving
> the level at INFO for the game package, if we are debugging
> a particular UI problem.
>
> In other projects I have often defined a separate logger for
> each class (or class hierarchy).
> But in reality I have never used that ultimate flexibity to set
> different log levels; in fact I've only changed the top level,
> which applies to all loggers.
>
> So I think we can best set loggers at the package level.
> I have already experimented with that and it works fine.
>
> Later I'll check in some code using that.
>
> Erik.
>


Ah ha...  That makes sense.

I agree, i'm not sure we need much more granularity. Package-level
loggers sounds appropriate to me.

---Brett.

Re: [Rails-devel] Logging

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

> > 
> > - how many loggers to create?
> > Perhaps simplest is one in the top of each class hierarchy.
> > One per package might be another approach, but then we would
> > need some central class with a protected static logger
> > for easy access by any class in each package.
> > 
> 
> 
> I'm not very familiar with how loggers translate to log files. I don't
> think we need more than one log file just yet. So, probably a single
> static log class that's accessible by everyone most closely duplicates
> what we currently do.

Loggers (in the log4j sense) do not relate to different log files,
but to the granularity with which log levels can be set to
different values for different parts of the code.

For instance, if we would define a logger for each package,
we could set the log level to DEBUG for the ui package whilst leaving 
the level at INFO for the game package, if we are debugging
a particular UI problem.

In other projects I have often defined a separate logger for 
each class (or class hierarchy). 
But in reality I have never used that ultimate flexibity to set
different log levels; in fact I've only changed the top level,
which applies to all loggers.

So I think we can best set loggers at the package level.
I have already experimented with that and it works fine.

Later I'll check in some code using that.

Erik.

Re: [Rails-devel] Logging

[Brett L. <wak...@gm...>]

On Thu, 2007-01-11 at 20:50 +0100, Erik Vos wrote:
> I'm considering to add log4j logging, to move
> (or duplicate) the current console messages to
> a log file. (This will not affect the Log Window,
> which is actually a misnomer for a Game Report window).
> 
> Any objections?
> 

None. I like log files. They're good for bug reports. ;-)

> Remain two questions:
> 
> - how many loggers to create?
> Perhaps simplest is one in the top of each class hierarchy.
> One per package might be another approach, but then we would
> need some central class with a protected static logger
> for easy access by any class in each package.
> 


I'm not very familiar with how loggers translate to log files. I don't
think we need more than one log file just yet. So, probably a single
static log class that's accessible by everyone most closely duplicates
what we currently do.


> - what configuration file? 
> Default is log4j.properties, but I am considering to
> include the log4j properties in a common properties file.
> This would require setting a system property on the command line
> (if possible with a default in the main() method).
> 

We definitely need our own configuration file, as we've discussed
before.

I think it's reasonable to expose a small subset of log4j settings in
our configuration file. 

Typical settings would be things like to enable/disable logging to a
file, logging verbosity, maximum log file size, etc.


> One additional item I would like to include in such a file
> would be a choice for the type of tile picture to use:
> GIF or SVG. Today I worked on another PC where the SVG's
> were not loaded yet, and it struck me again how much better
> the GIFs looked. So I would like to be able to set that
> as a preference.
> 

That's fine. 

The SVG code needs fixing. Right now, we're not really leveraging the
library as well as we could.

---Brett.

[Rails-devel] Logging

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

I'm considering to add log4j logging, to move
(or duplicate) the current console messages to
a log file. (This will not affect the Log Window,
which is actually a misnomer for a Game Report window).

Any objections?

Remain two questions:

- how many loggers to create?
Perhaps simplest is one in the top of each class hierarchy.
One per package might be another approach, but then we would
need some central class with a protected static logger
for easy access by any class in each package.

- what configuration file? 
Default is log4j.properties, but I am considering to
include the log4j properties in a common properties file.
This would require setting a system property on the command line
(if possible with a default in the main() method).

One additional item I would like to include in such a file
would be a choice for the type of tile picture to use:
GIF or SVG. Today I worked on another PC where the SVG's
were not loaded yet, and it struck me again how much better
the GIFs looked. So I would like to be able to set that
as a preference.

Any comments?

Erik Vos

[Rails-devel] Sourceforge tracker

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

I have gone through the Bugs and Feature Requests,
and updated those items that have been implemented
in the meantime, or that I won't take for whatever reason.

There was a request for some fixes to 1870.
Ahthough that is not yet a supported game, 
these fixes could be done easily by configuration.

However, while testing that I found that the tile counting
in cases where more than one yellow tile can be laid
still does not work correctly in all cases.
In particular, the C$StL extra tile in 1830 now
seems to break the logic again.
I will revisit and hopefully  fix that later.

Erik Vos

[Rails-devel] Compile errors fixed

[brett l. <wak...@gm...>]

I've commited versions of the two servlet files in /test that comment
them out entirely.

These servlets are not maintained and haven't been updated with the
API changes in quite some time.

This elimintates bogus compiler errors that were showing up and were
confusing to new developers.

---Brett

[Rails-devel] OperatingRound localised

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

All user messages from OperatingRound have now been localised.

Erik Vos

[Rails-devel] Revenue step Undo/redo

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

I have committed a number of changes.

The commit text:

Implemented Undo/Redo for the OR revenue entry and payout steps.
Some token laying fixes.
Split class Log into LogBuffer and MessageBuffer and changes method names
(this affects many classes).
Localised many messages in OperatingRound.

It may not be perfect yet, but the basics seem to work.

The disciplinating effect of implementing the new patterns throughout
turns out to be strong, and I am pleased how well it works out once the
basics are done.
This applies to the usage of the subclasses of
- PossibleAction to streamline the interaction between the GUI and the
engine
(which I hope will much facilitate the client/server communication once we
make that split),
- ModelObject to notify the GUI of state changes in the engine, and
- Move to implement Undo/Redo.

But there is still a lot of work to do on these aspects!

Erik Vos

Re: [Rails-devel] Planing some minor changes in the UI

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

I would say : give it a try.
 
I cannot judge how difficult the GUI conversion will be.
The GUI code structure has some deficiencies, the most important
perhaps being the complete lack of a Controller.
In particular the OR-related GUI code is complex and not very consistent.
 
Good luck!
 
Erik.
 
 



  _____  

From: rai...@li...
[mailto:rai...@li...] On Behalf Of Rainer
Muetze
Sent: Sunday 07 January 2007 16:42
To: rai...@li...
Cc: 'Brett Lentz'; eri...@hc...
Subject: [Rails-devel] Planing some minor changes in the UI



Hi,

 

as I discussed with Brett and Erik I would like to make some small changes
to the startup-sequence and the UI in general.

Here is a small summary for the thinks which I want to do.

 

Motivation for me:

Get familiar with the code by doing thinks I'm very familiar in and do not
disturb the on going implementation of the other too.

Later on I would like to help implementing the AI and/or
Internet-Interaction, maybe starting by calculating the revenue or which
ever will have the higher priority.

 

Why changing the startup-sequence:

1)  I want to start the program with a small disclaimer about copyrights.
Possible text would be (from Brett):

"Rails is a Java clone of the "18xx"-style games produced by Mayfair
Games(tm), Avalon Hill(tm), David Hecht, John Galt, Francis Tresham, and
various other authors. All rights reserved by the respective owners. No
challenge to their status is intended. Rails is intended as a play aid for
owners of each respective boardgame."

Maybe adding: "If a copyright owner wish a removing of the play aid of his
18xx-version, we will do so."

 

2) There is no check for the number of players selected and the maximum
number of players allowed in a game.

 

3) If we want to load a game we need an other entry-point. Same later on for
PBEM and Internet-Games.

 

Conclusion: Start with the main window and the disclaimer dialog.
Alternative with parameters, too speedup testing. 

Choose game-version and players in different dialogs (alternative check it
on OK).

 

I like the UI of rails in general, but there are a view thinks left to
optimize it.

I like the concept of MDI, but will not loose the opportunity of free
windows. We had a little discussion about MDI in rails because of the great
windows there, so the MDI could maybe not the right solution, if you will
not have the choise. Having Eclipse in mind I have looked for an open source
MDI framework. Found one, but that one will not give as the freedom of
changing InternalFrames into Windows and back. Checking Eclipse I found out,
that they use an own GUI-Framework instead of Swing - SWT and JFaces. I
don'nt think, that this is worse a change of the hole GUI-Framework. So may
changes would be small.

1) Make a rails-window-framework, with will include the MainMenu, a
ActionButtonToolbar and a InformationLine

2) Transform the current Windows to use the rails-window-framework

3) Add Preferences to choose look(&feel), which windows are permanent, save
window-positions, languages and other thinks, which are easy to implement
(wishes welcome)

 

After this changes I should be familiar with the code (and it will be march
I guess) and would like to do thinks, I have'nd done yet.

 

Regards

Rainer

 

 

Re: [Rails-devel] Compile Errors

[brett l. <wak...@gm...>]

Rainer -

The javax.servlet.* packages are from the J2EE SDK, so they won't be
present if you just have the J2SE SDK installed.

However, they are not necessary to run Rails. The main() methods are a
bit poorly documented, but there is an old proof-of-concept class for
running Rails as a Java servlet called test/GameTestServlet.java. It
hasn't received much attention lately and probably doesn't work
anymore.

The main() that runs the actively developed application is in
test/GameTest.java.

Also in test/ are a few other applications that we've used to
demonstrate early portions of our work or certain libraries, like
Batik. None of these are used for the main application.

---Brett


On 1/7/07, Rainer Muetze <rai...@we...> wrote:
> Hi,
> checked out the current CVS-Version and get some (38) compile errors. Most
> of it, because of can not import the javax.servlet.*. Would you please put
> it in the lib-dir or tell me, witch lib I have to download?
>
> Thanks
> Rainer
>
>
>

[Rails-devel] Planing some minor changes in the UI

[Rainer M. <rai...@we...>]

Hi,

=20

as I discussed with Brett and Erik I would like to make some small =
changes
to the startup-sequence and the UI in general.

Here is a small summary for the thinks which I want to do.

=20

Motivation for me:

Get familiar with the code by doing thinks I'm very familiar in and do =
not
disturb the on going implementation of the other too.

Later on I would like to help implementing the AI and/or
Internet-Interaction, maybe starting by calculating the revenue or which
ever will have the higher priority.

=20

Why changing the startup-sequence:

1)  I want to start the program with a small disclaimer about =
copyrights.
Possible text would be (from Brett):

"Rails is a Java clone of the "18xx"-style games produced by Mayfair
Games(tm), Avalon Hill(tm), David Hecht, John Galt, Francis Tresham, and
various other authors. All rights reserved by the respective owners. No
challenge to their status is intended. Rails is intended as a play aid =
for
owners of each respective boardgame."

Maybe adding: "If a copyright owner wish a removing of the play aid of =
his
18xx-version, we will do so."

=20

2) There is no check for the number of players selected and the maximum
number of players allowed in a game.

=20

3) If we want to load a game we need an other entry-point. Same later on =
for
PBEM and Internet-Games.

=20

Conclusion: Start with the main window and the disclaimer dialog.
Alternative with parameters, too speedup testing.=20

Choose game-version and players in different dialogs (alternative check =
it
on OK).

=20

I like the UI of rails in general, but there are a view thinks left to
optimize it.

I like the concept of MDI, but will not loose the opportunity of free
windows. We had a little discussion about MDI in rails because of the =
great
windows there, so the MDI could maybe not the right solution, if you =
will
not have the choise. Having Eclipse in mind I have looked for an open =
source
MDI framework. Found one, but that one will not give as the freedom of
changing InternalFrames into Windows and back. Checking Eclipse I found =
out,
that they use an own GUI-Framework instead of Swing - SWT and JFaces. I
don'nt think, that this is worse a change of the hole GUI-Framework. So =
may
changes would be small.

1) Make a rails-window-framework, with will include the MainMenu, a
ActionButtonToolbar and a InformationLine

2) Transform the current Windows to use the rails-window-framework

3) Add Preferences to choose look(&feel), which windows are permanent, =
save
window-positions, languages and other thinks, which are easy to =
implement
(wishes welcome)

=20

After this changes I should be familiar with the code (and it will be =
march
I guess) and would like to do thinks, I have'nd done yet.

=20

Regards

Rainer

=20

=20

[Rails-devel] Compile Errors

[Rainer M. <rai...@we...>]

Hi,
checked out the current CVS-Version and get some (38) compile errors. Most
of it, because of can not import the javax.servlet.*. Would you please put
it in the lib-dir or tell me, witch lib I have to download?

Thanks
Rainer

[Rails-devel] Token lays now undoable

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

OK, I have implemented undo/redo for token lays
along the lines that we have discussed. It seems to work.

Much of the token laying code has been rewritten, 
and several new classes and interfaces have been added,
including Token, TokenI and BaseToken.

The MapHex method moveTokens has disappeared. 
The new code to move tokens from the old to the new tile is simpler, 
and now also handles simple 2-to-1 and 3-to-1 station mergers,
like 1856 Toronto and 18EU Berlin/Vienna.
However, the code is still not smart enough to correctly
map old to new stations in 1830 OO-city upgrades.

Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf 
> Of brett lentz
> Sent: Sunday 31 December 2006 20:59
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Available tokens
> 
> It makes sense to me to make the object structure and interfaces as
> consistent as possible across object types.
> 
> It's also helpful to do this considering our JavaDoc needs 
> some work. ;-)
> 
> I also agree that it'll probably help to have a generic Token class
> when we implement Port tokens.
> 
> ---Brett.
> 
> On 12/31/06, Erik Vos <eri...@xs...> wrote:
> > I'm currently pondering whether or not it is worthwhile
> > to restructure the code to make token laying follow this pattern
> > as well (each lay would then become a transfer of a Token object
> > between two TokenHolder objects).
> >
> > While thinking about this I also keep in mind that different token
> > types exist (e.g. port tokens occur in several games).
> > It might be useful to have a generic Token class from which
> > specific token types can be subclassed.
> > (the existing Token class would then be renamed to GUIToken 
> or such).
> > You'll be aware that I already fairly consistently refer to the
> > usual tokens as BaseTokens.
> >
> > Erik.
> 
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the 
> chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
> &CID=DEVDEV
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 

Re: [Rails-devel] Available tokens

[brett l. <wak...@gm...>]

It makes sense to me to make the object structure and interfaces as
consistent as possible across object types.

It's also helpful to do this considering our JavaDoc needs some work. ;-)

I also agree that it'll probably help to have a generic Token class
when we implement Port tokens.

---Brett.

On 12/31/06, Erik Vos <eri...@xs...> wrote:
> I'm currently pondering whether or not it is worthwhile
> to restructure the code to make token laying follow this pattern
> as well (each lay would then become a transfer of a Token object
> between two TokenHolder objects).
>
> While thinking about this I also keep in mind that different token
> types exist (e.g. port tokens occur in several games).
> It might be useful to have a generic Token class from which
> specific token types can be subclassed.
> (the existing Token class would then be renamed to GUIToken or such).
> You'll be aware that I already fairly consistently refer to the
> usual tokens as BaseTokens.
>
> Erik.

[Rails-devel] Available tokens

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

I have committed code to show the number of available 'base' tokens
and the total number of tokens in both the GameStatus and
the ORPanel. The format is <available>/<total>.

Also included are some minor changes, and an empty BaseTokenMove
class as a start to make token laying undoable.

Currently, token laying does not follow the "move" pattern
that we use for most other items (trains, certificates, money),
and that makes undo/redo very easy to implement.
(Tile laying is the other exception, but that was pretty 
straightforward to handle.)
I'm currently pondering whether or not it is worthwhile
to restructure the code to make token laying follow this pattern
as well (each lay would then become a transfer of a Token object 
between two TokenHolder objects).

While thinking about this I also keep in mind that different token
types exist (e.g. port tokens occur in several games). 
It might be useful to have a generic Token class from which 
specific token types can be subclassed.
(the existing Token class would then be renamed to GUIToken or such).
You'll be aware that I already fairly consistently refer to the
usual tokens as BaseTokens. 

Erik.

[Rails-devel] Undoing tile lays

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

Over the past few days I have committed a bunch of changes,
including:

1. Allow private special properties to work if
the private is owned by a player (as in 1835).

2. Cleanups in localisation (some internal strings 
were unnessarily localised, 
these have been replaced by static final variables).

3. Tile lays can now (generally) be undone and redone.
I have added Undo and Redo buttons to the ORPanel;
perhaps these stand in the way a bit, we can always
improve that later.
One bug I could not fix yet: special tile lays, 
when undone, remain inaccessible. I don't see why,
and will fix that later.

Erik Vos

Re: [Rails-devel] Token laying etc.

[brett l. <wak...@gm...>]

Awesome.  I will definitely check out the changes soon.

I haven't had as much time to work on Rails as I'd like. There have been a
bunch of upheavals in my personal life.


---Brett.



On 12/3/06, Erik Vos <eri...@hc...> wrote:
>
> I've made a number of other improvement over this weekend.
>
> Token laying now also uses a PossibleAction subclass (LayToken)
> to manage normal and special-property token laying.
>
> The red prompt messages related to special properties now indicate
> whether the special tile/token lay is extra or not,
> and whether it is free or not (where that matters).
>
> Various other fixes to tile and token laying.
>
> I believe 1830 tile and token laying now works (again) as it should,
> and the logic behind it should be better prepared for other games.
>
> In 1835, major companies may lay two yellow tiles
> in the yellow phase. This already works.
>
> I've also made train ownership for 1835 minor companies optional.
>
> Next I will add the 1835 special properties, which deviate
> from the 1830 ones in that these apply whilst the privates
> are owned by players (privates can't be sold). This should be easy.
> The close-if-exercised rule will be the real new thing here.
>
> There is a lot of extra debug output on stdout, I will
> remove that once I feel the current code is robust enough.
>
> Erik Vos
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Token laying etc.

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

I've made a number of other improvement over this weekend.

Token laying now also uses a PossibleAction subclass (LayToken)
to manage normal and special-property token laying.

The red prompt messages related to special properties now indicate
whether the special tile/token lay is extra or not,
and whether it is free or not (where that matters).

Various other fixes to tile and token laying.

I believe 1830 tile and token laying now works (again) as it should,
and the logic behind it should be better prepared for other games.

In 1835, major companies may lay two yellow tiles
in the yellow phase. This already works.

I've also made train ownership for 1835 minor companies optional.

Next I will add the 1835 special properties, which deviate
from the 1830 ones in that these apply whilst the privates 
are owned by players (privates can't be sold). This should be easy.
The close-if-exercised rule will be the real new thing here.

There is a lot of extra debug output on stdout, I will
remove that once I feel the current code is robust enough.

Erik Vos

[Rails-devel] Better tile laying management

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

It's been quiet for a while, but work has still progressed,
although a lot slower than in the past.

In 1830, the laying of unconnected tiles because of private special 
properties turned out to be broken a while ago.
I have now reorganised tile laying management completely, 
along the lines of the Possible Actions class hierarchy introduced a while
ago. 
Both normal and special tile lay allowances are now governed by LayTile
objects.

I hope this change has made tile laying management more transparent,
and it should now be pretty well prepared to handle the
numerous special cases in other games, and also for the 
lucky day that we will have implemented routes and connectivity,
so that we can tell the UI on which hexes tiles can be laid.

One remaining glitch is, that if a company owns the C&StL, and
first lays a "normal" tile, the extra info on the allowed
extra tile lay disappears from the prompt message line
(but the extra tile can be laid all the same).
I'm not sure why this is so. Admittedly, the UI code around
the prompt display is still pretty badly organised.
  
I'll continue to work on this and related things,
for instance special token laying,
but it became time to commit some of this stuff.

Erik Vos

Re: [Rails-devel] Allowed user actions (was: M&H)

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

> > For this end we will need a new "allowed actions" class hierarchy,
> > derived from some abstract base class. The result of the 
> above-mentioned
> > "what can I do" call would then be a List of objects which are
> > instances of subclasses of that base class. The existing class
> > BuyableTrain would become such a subclass.
> >
> > An example of such an object would be "Lay a tile on hex XY".
> > This would already work for the special extra tile lays.
> > We can't yet restrict normal tile lays, so we would
> > have a blanket "lay a tile anywhere" object instead.
> > Once we have route awareness, this would be replaced
> > by a series of objects, one for each hex where a tile can be laid.
> >
> > (I think this approach would also make the future client/server
> > separation easier: a main component of the client-to-server 
> information
> > stream could exist of a serialized version of this List).
> >
> > I'm looking for a good and shortish name for the base class.
> > We have already consumed Action, Move and Option.
> > AllowedAction might do, or UserOption, but I would prefer a short
> > one-word name that can easily be incorporated in its subclass names.
> > What about Play?
> 
> 
> Overall, I like this idea.
> 
> I think AllowedAction or UserAction are good.  The problem with
> single-words is that they're very ambiguous.
> 
> I'd like to keep the API reasonably descriptive. Hopefully it will
> make the learning curve for any new developers slightly less steep.

For clarity (and to open up name space), I have renamed the package 
game.action to game.move and the old class (game.action.)Action to 
(game.move.)MoveSet.

A new package game.action will hold the allowed action classes.
The base class is PossibleAction and I have started with LayTile.

I hope these changes does not create too much confusion....

Erik.

Re: [Rails-devel] Allowed user actions (was: M&H)

[brett l. <wak...@gm...>]

On 8/14/06, Erik Vos <eri...@hc...> wrote:
> > One of these days, I'd really like to get to Essen.
>
> Better postpone that to the end of October,
> when the 18xx-ers and other gamers can be seen in the wild there.
>

Yeah, that's what I was meaning. ;-)


---Brett.

Re: [Rails-devel] Allowed user actions (was: M&H)

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

> One of these days, I'd really like to get to Essen.

Better postpone that to the end of October, 
when the 18xx-ers and other gamers can be seen in the wild there.

I'll probably be there Saturday 21th, 
also to pick up some games from John.

Erik.