rails-devel — List for discussion of Rails development

Re: [Rails-devel] Next steps (was: Save/Load works!)

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

On Mon, 2007-07-23 at 22:11 +0200, Erik Vos wrote:
> > > Next I will start looking at implementing some more games.
> > > Not sure which ones; the less special rules a game has,
> > > the greater the chance that it can be done pretty quickly.
> > 
> > My vote is 1856 or 1870. We've already got the maps in, so all that's
> > really left are the rules for the privates and maybe the double yellow
> > tile laying option (for 70), loans and nationalization (for 56).
> 
> And 1870 price protection! That and the 1856 nationalization
> do not count as simple matters to me, but I will have a look.
> I was rather thinking about 1851, 18AL, 18GA and perhaps 18EU.
> 1835 is already half done, but there the Prussian formation is the
> bottleneck.
> We will see.

Those all sound fine. There's a few different games that deal with each
of the things that are in 1856 and 1870 (e.g. nationalization, price
protection, etc), so at some point we'll need to implement those.
Though, it certainly doesn't have to be the next thing we tackle.

A few months back, I picked up a copy of 1861, so I was considering
adding in the map and tile counts for it. Due to its complexity, I don't
expect us to be implementing it until we've tackled many of the simpler
games. ;-)

I also have been thinking about building out the website area that
Sourceforge gives us. Now that we've got a nice looking map display,
sticking some screenshots up there might be a good way to show the
progress we're making.


 ---Brett.


Next, upon a stool, we've a sight to make you drool.
Seven virgins and a mule, keep it cool, keep it cool.
		-- ELP, "Karn Evil 9" (1st Impression, Part 2)

Re: [Rails-devel] Save/Load works!

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

> > Brett, as I know you are working on a release, please let me know 
> > when I can upload my new changes, as I don't want to 
> interfere with you.
> > 
> 
> Go ahead and just commit now. I'm having a problem with getting log4j
> used by our jar. It keeps throwing NoClassDefFoundError for 
> Logger. I'm
> not quite sure exactly what's wrong.

OK, done.

There is a new section in my.properties to specify the save
directory and some save filename properties.
None if this is absolutely needed, but the save directory
is recommended.

For Save, a default file name is proposed containing the
game name and the current date/time. 
The default extension is .rails.
The file name can be changed, and once that is done,
new Saves will also use that file name (in the same run, that is).

The save file is a serialized bunch of Java objects,
so it is an unreadable binary file. I tried to find a 
generic decoding utility, but could not find one so far.

With Load such a saved file can be read and the game is resumed
at the Save point (I hope). Yes, you can Undo until before the Save point.

> > Next I will start looking at implementing some more games.
> > Not sure which ones; the less special rules a game has,
> > the greater the chance that it can be done pretty quickly.
> 
> My vote is 1856 or 1870. We've already got the maps in, so all that's
> really left are the rules for the privates and maybe the double yellow
> tile laying option (for 70), loans and nationalization (for 56).

And 1870 price protection! That and the 1856 nationalization
do not count as simple matters to me, but I will have a look.
I was rather thinking about 1851, 18AL, 18GA and perhaps 18EU.
1835 is already half done, but there the Prussian formation is the
bottleneck.
We will see.

> Also, we should look at creating a way to show the status of each game
> in the Options UI so that users know which games are playable 
> and which
> aren't.

Hmm, yes. A simple properties file would do, I guess.

Erik.

Re: [Rails-devel] Save/Load works!

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

On Mon, 2007-07-23 at 21:39 +0200, Erik Vos wrote:
> It definitely needs more testing, which I will do in the next few days,
> but so far everything seems to work.
> 
> Amazing, how simple it was after all the preparational work
> in the past 12 months on Undo/Redo and, even more important,
> the game.action package. There definitely is room for more
> cleanups, but the basic program flow now seems very solid to me,
> and a good basis for further development.
> 
> Brett, as I know you are working on a release, please let me know 
> when I can upload my new changes, as I don't want to interfere with you.
> 

Go ahead and just commit now. I'm having a problem with getting log4j
used by our jar. It keeps throwing NoClassDefFoundError for Logger. I'm
not quite sure exactly what's wrong.


> Next I will start looking at implementing some more games.
> Not sure which ones; the less special rules a game has,
> the greater the chance that it can be done pretty quickly.

My vote is 1856 or 1870. We've already got the maps in, so all that's
really left are the rules for the privates and maybe the double yellow
tile laying option (for 70), loans and nationalization (for 56).

Also, we should look at creating a way to show the status of each game
in the Options UI so that users know which games are playable and which
aren't.



 ---Brett.


"You're not one of us."
"I don't think I'm one of them, either," said Brutha. "I'm one of
mine."
(Small Gods)

[Rails-devel] Save/Load works!

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

It definitely needs more testing, which I will do in the next few days,
but so far everything seems to work.

Amazing, how simple it was after all the preparational work
in the past 12 months on Undo/Redo and, even more important,
the game.action package. There definitely is room for more
cleanups, but the basic program flow now seems very solid to me,
and a good basis for further development.

Brett, as I know you are working on a release, please let me know 
when I can upload my new changes, as I don't want to interfere with you.

Next I will start looking at implementing some more games.
Not sure which ones; the less special rules a game has,
the greater the chance that it can be done pretty quickly.

Erik Vos
eri...@hc...
fax: 084 716 7187 

Re: [Rails-devel] SVG Tile cleanups

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

On Mon, 2007-07-23 at 20:52 +0200, Erik Vos wrote:
> > Just found I had overlooked the GUIHex classes.
> > Sorry for the confusion, it looks very good now.
> 
> ... at least with SVG.
> The GIF tiles are now three times as large as they should be!
> 
> I would suggest to make the scaling factor extension-dependent.
> If you want I can upload code with that effect.


Oops!  I forgot to even test the GIFs.

There are a bunch of things that we need to do with the scaling code.  

Ideally, I'd like to be able to have the scale automatically adjusting
when the window is resized.

I'll work on fixing the GIF tile rendering, and then try to find a more
generic tile rendering solution.

 ---Brett.


Algol-60 surely must be regarded as the most important programming language
yet developed.
		-- T. Cheatham

Re: [Rails-devel] SVG Tile cleanups

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

> Just found I had overlooked the GUIHex classes.
> Sorry for the confusion, it looks very good now.

... at least with SVG.
The GIF tiles are now three times as large as they should be!

I would suggest to make the scaling factor extension-dependent.
If you want I can upload code with that effect.

Erik.

Re: [Rails-devel] SVG Tile cleanups

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

> I assume you've merged all changes into your local code?

Just found I had overlooked the GUIHex classes.
Sorry for the confusion, it looks very good now.

> > - I'm well on my way with Save/Load. Save is done, but, of course,
> > Load is the difficult part. I can't guarantee completion in the
> > 2=BD weeks before I'm going on vacation (Aug. 10th), but the =
prospect
> > isn't bad, so it might be worth the wait.
>=20
> We can do that in a separate release.

OK.

Erik.

Re: [Rails-devel] SVG Tile cleanups

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

On 7/22/07, Erik Vos <eri...@hc...> wrote:
> > I've completed the tile adjustments and committed them.  Also, I've
> > committed some adjustments to the tile scaling constants.
> >
> > Now, when we load a tile, it's a significantly smaller image that
> > doesn't need much rescaling. This simplifies the drawing calculations
> > so that we don't lose as much information when we rescale the image
> > during a paint().
> >
> > This improves the look of the SVG tiles immensely. I'm really happy
> > with the results.
>
> Well, the tiles are a lot smaller, but the map isn't, so the result
> does not look good on my PC. I'll send you a screenshot per personal mail=
.
> Do I need some property setting?
>

None that I know of.  I'm using the my.properties that's in CVS.

I assume you've merged all changes into your local code?


> > With this tile work and the undo/redo work complete, if there are no
> > objections, I'll do another release in the next day or so.
>
> No objections. Just two remarks:
>
> - I'm well on my way with Save/Load. Save is done, but, of course,
> Load is the difficult part. I can't guarantee completion in the
> 2=BD weeks before I'm going on vacation (Aug. 10th), but the prospect
> isn't bad, so it might be worth the wait.
>


We can do that in a separate release.


> - Not sure, but I may have fixed one or two remaining bugs while working
> on Save/Load. If you want, I could upload the current code (with Save/Loa=
d
> still disabled). It should all work, but that would need extra testing.
>

Let's wait until the rest of Save/Load is finished.


----Brett.

Re: [Rails-devel] SVG Tile cleanups

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

> I've completed the tile adjustments and committed them.  Also, I've
> committed some adjustments to the tile scaling constants.
>=20
> Now, when we load a tile, it's a significantly smaller image that
> doesn't need much rescaling. This simplifies the drawing calculations
> so that we don't lose as much information when we rescale the image
> during a paint().
>=20
> This improves the look of the SVG tiles immensely. I'm really happy
> with the results.

Well, the tiles are a lot smaller, but the map isn't, so the result
does not look good on my PC. I'll send you a screenshot per personal =
mail.
Do I need some property setting?
=20
> With this tile work and the undo/redo work complete, if there are no
> objections, I'll do another release in the next day or so.

No objections. Just two remarks:

- I'm well on my way with Save/Load. Save is done, but, of course,=20
Load is the difficult part. I can't guarantee completion in the
2=BD weeks before I'm going on vacation (Aug. 10th), but the prospect
isn't bad, so it might be worth the wait.

- Not sure, but I may have fixed one or two remaining bugs while working =

on Save/Load. If you want, I could upload the current code (with =
Save/Load
still disabled). It should all work, but that would need extra testing.

Erik.

Re: [Rails-devel] SVG Tile cleanups

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

On 7/17/07, Erik Vos <eri...@hc...> wrote:
> > I've committed the first batch of cleanups for the SVG tiles.
> >
> > The last time I touched these files, it looks like there was some
> > slight variation in the hex size and positioning within the image
> > canvas. This was causing some unpredictable positioning when these
> > images were laid out on the map as well as some strange skewing when
> > applying an affine transform.
> >
> > So, I'm going back and adjusting all of the tiles to better fit within
> > the canvas dimensions.
> >
> > I'm fairly happy with the results. The 1830 map looks significantly
> > more uniform.
>
> Yes, it looks a lot better now, though still slightly less good than
> the .gif tiles that I had reverted to in the meantime.
>
> I hope your further efforts will clean it all up!
>


I've completed the tile adjustments and committed them.  Also, I've
committed some adjustments to the tile scaling constants.

Now, when we load a tile, it's a significantly smaller image that
doesn't need much rescaling. This simplifies the drawing calculations
so that we don't lose as much information when we rescale the image
during a paint().

This improves the look of the SVG tiles immensely. I'm really happy
with the results.

With this tile work and the undo/redo work complete, if there are no
objections, I'll do another release in the next day or so.

---Brett.

Re: [Rails-devel] SVG Tile cleanups

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

> I've committed the first batch of cleanups for the SVG tiles.
> 
> The last time I touched these files, it looks like there was some
> slight variation in the hex size and positioning within the image
> canvas. This was causing some unpredictable positioning when these
> images were laid out on the map as well as some strange skewing when
> applying an affine transform.
> 
> So, I'm going back and adjusting all of the tiles to better fit within
> the canvas dimensions.
> 
> I'm fairly happy with the results. The 1830 map looks significantly
> more uniform.

Yes, it looks a lot better now, though still slightly less good than 
the .gif tiles that I had reverted to in the meantime.

I hope your further efforts will clean it all up!

Erik.

[Rails-devel] Save/Load thoughts

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

I am turning my attention to the long-awaited Save/Load options,
as I believe we are now ready to start working on that.

Save/Load amounts to somehow serializing (i.e., writing away to a file)
and deserializing (reading) the current state of the program. 
Perhaps it stands to reason to use Java's inherent serialization
feature for this purpose, but I have zero experience with it,
so I'm looking for the best way to start with it.

A while ago I thought that serialization of the Undo stack would be
a simple approach, but recently it occurred to me that, now that
we have unified all player actions as PossibleAction subclass objects,
it might be even simpler to build a player action stack, 
and serialize that stack on a Save command.

The main problem is, of course, to reconstruct the previous state
during deserialization on a Load command. The action objects contain 
references to all kinds of permanent objects (i.e., which existed 
before the action), so we cannot let deserialization recreate those objects
(tiles, companies, certificates, trains etc.). All these objects are
static in the sense that they are created at game start and do not
change except for the contained owner and other relational references.

So I believe we should give each such object a unique identifier (String)
and serialize that identifier. Deserialization then will include just
a lookup of these objects rather than a recreation.

This implies that all PossibleAction subclasses must get their own
writeObject() and readObject() methods.

The idea is, that a Load will first read the game, variant, and player
names, after which the game is started normally. Then 
all the saved player actions are read and executed. UI updating
will be suppressed until the load is complete. 

There may be other ways to save a game (such as serializing all
state variables), but that approach looks much more complex to me,
and in any case I shy away from such an approach.

As always: comments welcome.

Erik Vos

[Rails-devel] SVG Tile cleanups

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

I've committed the first batch of cleanups for the SVG tiles.

The last time I touched these files, it looks like there was some
slight variation in the hex size and positioning within the image
canvas. This was causing some unpredictable positioning when these
images were laid out on the map as well as some strange skewing when
applying an affine transform.

So, I'm going back and adjusting all of the tiles to better fit within
the canvas dimensions.

I'm fairly happy with the results. The 1830 map looks significantly
more uniform.

The other thing I'm working on, but haven't committed yet is a
solution for the horrible dithering on the map. In large part, this is
due to AffineTransform's scale() method. We use HexIcons for the tile
lay preview, which does an excellent smooth rescaling. I'd love to use
HexIcons for the map, but there's no way to rotate a HexIcon. So, I'm
exploring a few different ways of removing the need to use
AffineTransform's scale() method.

---Brett.

[Rails-devel] Processing cycle

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

As I remarked yesterday, player action selection and processing
has now been centralised by passing these through two "Manager" classes,
oen at the UI/client side and one at the back-end/server side.
These activities have also been highly unified by implementing all action
selection 
options and executed actions by means of PossibleAction subclass objects.

I think it is a good idea to write down the whole process cycle,
which is what I will try to do below.
Should we ever write a Rails Developer Handbook, this could be one 
if its chapters.

For a start, we can take any point in the cycle, so let's choose one.

1. The player who has the turn selects the next action to take
by pressing a button, selecting a menu item, and/or filling in some
value in a UI entry field or a dialog. On program level, this boils down
to picking one entry from an ArrayList<PossibleAction>, and (where
needed) setting all required attributes to further specify that action
(for instance, when laying a tile: the hex location, tile id, and tile
orientation).
The acting player is also added. This work is all done in the classes 
that constitute the UI for the current type of round. 

2. The selected and completed PossibleAction object is passed to 
GameUIManager.processOnServer().

3. GameUIManager.processOnServer() passes this action to
GameManager.process().
See 7 for further actions taken when the latter method has returned
its result.

4. GameManager.process() does some common checks first:
- does the action player really have the turn?
- does the passed object really occur in the previous PossibleAction list?
Then the action is passed to the process() method of the current Round
subclass (StockRound, OperatingRound,etc.), unless it is a (forced) Undo
or a Redo, which are executed here immediately.
See 6 for further actions taken when the round-specific process() method 
has returned its result.

5. The current round's process() method does the remaining processing.
This includes:
- complete validation (if invalid, it puts a message in the display buffer
and returns false; but if this occurs, it is a program error - 
or someone is trying to crack the game!),
- execution, including all side effects, up to and including round changes.
To start a new round, GameManager.nextRound() is called.

6. GameManager.process() then calls the current (possibly changed!) round's
setPossibleActions() method. This method refills the PossibleAction list.
All possible actions are represented by a specific object.
This includes Undo/ForcedUndo/Redo, but these common actions are added
by GameManager.process() itself.
Finally the result (true=success, false=error) is returned.

7. GameUIManager.processOnServer() continues:
- A report of the player's action is added to the Report Window.
- updateUI() is called to check if the round has changed. 
If so, the old round's window is finished and the new round's window
intialised.

8. Also in updateUI(), the updateStatus() method of the (now) current window
is called. 
This method prepares the screen for the next player action 
by enabling the right menu options and buttons, etc. 
This UI updating is based upon the current PossibleActions list 
(to which the UI currently has direct access).

9. Back in processOnServer():
- The Undo/Redo menu items are en/disabled as appropriate,
- The current window's processImmediateAction() method is called.
This method executes any forced actions, that must be executed immediately 
by a modal dialog (i.e. without waiting for a player action). 
The only currently existing example is the par price setting for B&O 
(see previous post).

10. Finally, the current round's window displays any error or other 
messages (I'll probably move this action to processOnServer() as well).

11. The player gets the turn to select the next action.

The main point of this cycle is that it applies to all types of round,
so several round-specific idiosyncrasies have been removed.

A new interface ActionPerformer is implemented by all UI window classes
to define all methods these windows must implement (including
those that GameUIManager.processOnServer may call).



Erik Vos

[Rails-devel] Undo special cases

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

One problem I faced whilst implementing Undo/Redo was, that in some
cases a player turn solely exists of answering a modal dialog.
In such cases the player does not have a choice what action to take:
the type of action is forced. 

A modal dialog, though, breaks the Undo chain in the sense, that it 
prohibits all actions but answering the dialog. 
So it also prohibits another Undo.

I encountered this problem in two different cases, and for each case
I have implemented a different solution (for good reasons, I think).

The first case occurs when only one bid has been placed on the B&O private
in the start round. In that case, buying is automatic, the player
only must select the par price. This is done in a modal dialog.

I have solved this problem by inserting an extra step before the par
price setting dialog, in which the player must press "Buy" before
the dialog is shown. The B&O private is preselected, no other actions
are allowed. However, this extra step is only inserted after an Undo action.
It is omitted in the normal forward course of actions and after Redo.

The second case can occur when the first 4- or 5-train has been bought,
and one or more companies exceed their train limit and must discard a train.
In this case a modal dialog is shown where the player must select the
train to discard.

The solution I have chosen here is to link the discard actions to the
preceding train buying action, in the sense that the whole lot is undone
together, including the train buying action. Again, the Redo remains
as it was: one action at a time.

The second solution is far easier to use: just add one call to 
MoveSet.setLinkedToPrevious() following MoveSet.start(). 
But I don't think we should use this linkage in the B&O case,
which is why I have implemented a more complex solution there.
It is possible that buying the SVNRR triggers the whole start round
to roll up, and it does not smell right to me to undo that as a whole
when perhaps only a different B&O par price should be set.

Erik Vos

[Rails-devel] Undo/Redo completed

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

I have uploaded another bunch of changes, 
with which I think Undo/Redo is now about complete.

I have tested fairly extensively, but certainly not exhaustively.
In separate posts I will comment on some special cases 
and aspects that now have taken a different and, I hope, final form.

The UI has hardly changed. The Status window now has a separate
Moderator menu that contains the Forced Undo (which can cross
player turns, unlike the normal player undo). The Redo items in the
old Move and the new Moderator menu are still identical.

The StartRound window no longer has a Move menu, and I am considering
to remove the Undo/Redo buttons from the OR Window as well. 
Undo/Redo handling has been completely centralised and can always be
triggered form the Status window, regardless the current round.

A new class GameUIManager combines the old GameUILoader and
the now centralised handling of user actions at the UI side.
Also round changes, causing window switching, is detected there.

Its counterpart on the server side is the existing GameManager class,
which now catches all player actions and hands these to the current 
Round subclass, except Undo/Redo, which are processed immediately.

The intention is to centralise all traffic between client/UI/View 
and server/Back-end/Model between these two classes in the future.

Erik Vos

Re: [Rails-devel] Changes & UI ideas

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

On Thu, 2007-07-05 at 21:55 +0200, Erik Vos wrote:
> > 
> > > Talking about popups, I am also considering to replace some popup
> > > choice lists by a set of radio buttons, at least in those 
> > cases where
> > > a choice must be made between equivalent options, such as 
> > in selecting
> > > a company start price. The current choice list initially shows 
> > > the top price ($100) only, and the list must be scrolled to 
> > see the other
> > > values. 
> > > I think it would be better to show all prices on equal footing.
> > > 
> > 
> > It's certainly worth trying. Perhaps this is a good option to make a
> > user-configurable option? 
> > 
> > Would it be much work or complicate things unnecessarily to have both
> > layout options available?
> 
> One option for all such choice lists together, or one option per choice
> list?
> It is certainly doable, and not really a big deal, but it looks a bit like 
> overkill to me to apply it to all such lists.

When starting a game, have a selectable option of choosing your
preferred list UI: dropdowns or radio button lists.

This kind of option could be completely unnecessary, but it seems like a
good potential candidate for just letting the user choose what they
prefer.

 ---Brett.


Alexander Hamilton started the U.S. Treasury with nothing - and that was
the closest our country has ever been to being even.
	-- The Best of Will Rogers

Re: [Rails-devel] Changes & UI ideas

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

> > In particular I think that the payout decision can better be done 
> > in a popup than by the standard buttonsm which are renamed 
> for that purpose.
> > 
> > Perhaps the revenue entry should as well be put into a popup.
> > 
> 
> Just to get this out of the way, I despise pop-ups.  I really 
> hate apps
> that over-use pop-ups (especially modal pop-ups) to present every
> niggling little detail to the user and force the user to click an OK
> button to go back to whatever they were doing before the pop-up
> interruption.
> 
> I don't want to get into the habit of forcing things into the user's
> face with pop-ups unless it's absolutely necessary.

I fully agree with that. 
 
> That being said, I do think there are a few, occasional good things to
> put into a pop-up, such as critical application errors.
> 
> Right now, the popup for setting the value of a new company is okay
> simply because it's one of the few decisions that *must* be 
> made before
> play can move forward. So, having that be an interruption is, to me, a
> good use of a pop-up.

Indeed, I'm only talking about decisions that must be taken before
anything else can be done.
The payout/withhold choice (and 'split', in some games) is 
such an inescapable decision. As long as we can't calculate revenue,
revenue entry is also required, but we can leave that as it is now.

> > I fact I'm inclining to an approach previously proposed by Brett,
> > to have a fixed set of buttons as in the 1830 PC game, which 
> > are enabled/disabled as appropriate. I'm not sure if buttons should
> > also be added to initiate tile and token laying, as that 
> would imply 
> > an extra mouse click.
> > 
> 
> Yes. I'd much prefer this style of interface where all of the
> information needed to play the game is on a single "screen". 
> Being that
> we're already using a multi-window approach, I'd like to keep 
> the total
> number of windows to a minimum.
> 
> 
> 
> > Having a fixed set of buttons will also give a quieter look -
> > it's now a bit chaotic with buttons appearing and 
> disappearing all the time.
> > Special actions (like the M&H/NYC swap) could be put under 
> a "Special"
> > button.
> > Undo/Redo would be moved to a menu bar, as in the other windows.
> > Comments?
> 
> Agreed.  I don't mind having context-specific buttons that appear and
> disappear from the button list. However, I do agree that
> enabling/disabling existing buttons is easier on the window 
> layout than
> adding/subtracting whole buttons.
> 
> 
> > Talking about popups, I am also considering to replace some popup
> > choice lists by a set of radio buttons, at least in those 
> cases where
> > a choice must be made between equivalent options, such as 
> in selecting
> > a company start price. The current choice list initially shows 
> > the top price ($100) only, and the list must be scrolled to 
> see the other
> > values. 
> > I think it would be better to show all prices on equal footing.
> > 
> 
> It's certainly worth trying. Perhaps this is a good option to make a
> user-configurable option? 
> 
> Would it be much work or complicate things unnecessarily to have both
> layout options available?

One option for all such choice lists together, or one option per choice
list?
It is certainly doable, and not really a big deal, but it looks a bit like 
overkill to me to apply it to all such lists.

> > As an experiment, I have replaced the par price choice list, 
> > that is shown when starting a company, by a set of radio buttons. 
> > I have /not/ replaced the price list that pops up when buying 
> > the B&O private, so you can still compare the two possibilities. 
> > Let me know what you think about it.
> > 
> 
> I'll check it out.
> 
> > >From here I will continue to complete Undo/Redo to the
> > point that perhaps Save/Load can be implemented.
> > By then I think we will have a firm enough basis to resume adding
> > more functionality.
> 
> Awesome. I think we can do another release soon, perhaps when the last
> bit of Undo/Redo work is complete but before you start on Save/Load?

Yes, that would be a good moment. Should not take too long.

Erik.

Re: [Rails-devel] Changes & UI ideas

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

On Thu, 2007-07-05 at 21:18 +0200, Erik Vos wrote:

> I'm no longer very happy with the varying use of the OR window buttons.
> In particular I think that the payout decision can better be done 
> in a popup than by the standard buttonsm which are renamed for that purpose.
> 
> Perhaps the revenue entry should as well be put into a popup.
> 

Just to get this out of the way, I despise pop-ups.  I really hate apps
that over-use pop-ups (especially modal pop-ups) to present every
niggling little detail to the user and force the user to click an OK
button to go back to whatever they were doing before the pop-up
interruption.

I don't want to get into the habit of forcing things into the user's
face with pop-ups unless it's absolutely necessary.

That being said, I do think there are a few, occasional good things to
put into a pop-up, such as critical application errors.

Right now, the popup for setting the value of a new company is okay
simply because it's one of the few decisions that *must* be made before
play can move forward. So, having that be an interruption is, to me, a
good use of a pop-up.

> I fact I'm inclining to an approach previously proposed by Brett,
> to have a fixed set of buttons as in the 1830 PC game, which 
> are enabled/disabled as appropriate. I'm not sure if buttons should
> also be added to initiate tile and token laying, as that would imply 
> an extra mouse click.
> 

Yes. I'd much prefer this style of interface where all of the
information needed to play the game is on a single "screen". Being that
we're already using a multi-window approach, I'd like to keep the total
number of windows to a minimum.



> Having a fixed set of buttons will also give a quieter look -
> it's now a bit chaotic with buttons appearing and disappearing all the time.
> Special actions (like the M&H/NYC swap) could be put under a "Special"
> button.
> Undo/Redo would be moved to a menu bar, as in the other windows.
> Comments?

Agreed.  I don't mind having context-specific buttons that appear and
disappear from the button list. However, I do agree that
enabling/disabling existing buttons is easier on the window layout than
adding/subtracting whole buttons.


> Talking about popups, I am also considering to replace some popup
> choice lists by a set of radio buttons, at least in those cases where
> a choice must be made between equivalent options, such as in selecting
> a company start price. The current choice list initially shows 
> the top price ($100) only, and the list must be scrolled to see the other
> values. 
> I think it would be better to show all prices on equal footing.
> 

It's certainly worth trying. Perhaps this is a good option to make a
user-configurable option? 

Would it be much work or complicate things unnecessarily to have both
layout options available?


> As an experiment, I have replaced the par price choice list, 
> that is shown when starting a company, by a set of radio buttons. 
> I have /not/ replaced the price list that pops up when buying 
> the B&O private, so you can still compare the two possibilities. 
> Let me know what you think about it.
> 

I'll check it out.

> >From here I will continue to complete Undo/Redo to the
> point that perhaps Save/Load can be implemented.
> By then I think we will have a firm enough basis to resume adding
> more functionality.

Awesome. I think we can do another release soon, perhaps when the last
bit of Undo/Redo work is complete but before you start on Save/Load?

 ---Brett.


The trouble with being punctual is that people think you have nothing more
important to do.

[Rails-devel] Changes & UI ideas

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

I have committed a bunch of changes, mainly to bring the
OR Model/View interface in line with the recent changes to 
other types of round. I've also cleaned up some old code.

UI changes are minimal, but I have been pondering a few more.

I'm no longer very happy with the varying use of the OR window buttons.
In particular I think that the payout decision can better be done 
in a popup than by the standard buttonsm which are renamed for that purpose.

Perhaps the revenue entry should as well be put into a popup.

I fact I'm inclining to an approach previously proposed by Brett,
to have a fixed set of buttons as in the 1830 PC game, which 
are enabled/disabled as appropriate. I'm not sure if buttons should
also be added to initiate tile and token laying, as that would imply 
an extra mouse click.

Having a fixed set of buttons will also give a quieter look -
it's now a bit chaotic with buttons appearing and disappearing all the time.
Special actions (like the M&H/NYC swap) could be put under a "Special"
button.
Undo/Redo would be moved to a menu bar, as in the other windows.
Comments?


Talking about popups, I am also considering to replace some popup
choice lists by a set of radio buttons, at least in those cases where
a choice must be made between equivalent options, such as in selecting
a company start price. The current choice list initially shows 
the top price ($100) only, and the list must be scrolled to see the other
values. 
I think it would be better to show all prices on equal footing.

Other cases are different. For instance, train buying has a preferred choice

(the next train from the Bank) and I think it's OK to show just that one on
top.

As JOptionPane does not have a radio button version, I have created 
a simple generic dialog (RadioButtonDialog) that takes an arbitrary number 
of options (a String array). These options are shown as a list of radio
buttons, 
with OK and Cancel buttons.
As an experiment, I have replaced the par price choice list, 
that is shown when starting a company, by a set of radio buttons. 
I have /not/ replaced the price list that pops up when buying 
the B&O private, so you can still compare the two possibilities. 
Let me know what you think about it.


>From here I will continue to complete Undo/Redo to the
point that perhaps Save/Load can be implemented.
By then I think we will have a firm enough basis to resume adding
more functionality.

Erik Vos

Re: [Rails-devel] Fixes & sorting

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

 

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf 
> Of brett lentz
> Sent: Sunday 24 June 2007 22:06
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Fixes & sorting
> 
> On 6/24/07, Erik Vos <eri...@hc...> wrote:
> > > > > Ahhh...   how about we relabel it as "Master Undo 
> (for testing)" ?
> > > >
> > > > Hmm, isn't that a bit longish?
> > > > I was inspired by the vi commands that get a forcing 
> character when
> > > > suffixed with a !, for instance q! forces quit where q doesn't.
> > > > I agree that some explanation is needed, perhaps a tooltip?
> > > >
> > >
> > >
> > > A tooltip would help, but in general having two menu 
> options named the
> > > same thing is going to be confusing.
> > >
> > > I don't really see a problem with a long menu option. We're not
> > > limited for space there.
> >
> > Actually, I meant that the appearance of two options is temporary.
> > ultimately, I think there would be only one undo option 
> (labelled just
> > "Undo"),
> > and it would depend on the user's role (player or 
> Master/Moderator) what
> > its meaning would be.
> >
> s> For now I suppose we have two ways in which the program 
> can be used:
> >
> > 1. "Hotseat", which (if I'm right) means that players take 
> turns behind one
> > screen.
> > In that case, the (restricted) player undo would apply.
> >
> > 2. Moderator, in which case one person replays or moderates a game.
> > In this case the unrestricted version would apply.
> >
> > What about adding a startup option (two radio buttons?)
> > to select between these two usages? Then the "Undo!" could go.
> >
> 
> Here are some other ways we could do it:
> 
> 1) We could add a new temporary drop-down menu for testing new
> functionality, and just enable/disable it this new menu with a
> "development mode" startup option.
> 
> 2) We can move the "player undo" back onto the game status window,
> next to the Done button.  Then rename the Move menu to something like
> "Moderator", so that the Undo that's in there is more clearly a
> "Moderator Undo"
> 
> 
> 
> I like #1 because then we can add anything in there without worrying
> too much about choosing a permanent position within the UI for it.
> This also allows us to have these potentially confusing UI elements
> disabled by default when we ship out new JARs.
> 
> I like #2 because it creates a clear differentiator that may be useful
> for other features and could be a less temporary (more permanent) way
> of presenting that feature.
 
Both look good to me. In fact we could marry your two options by leaving
Move in *and* adding Moderator.

Another factor to look at is consistency between the various screens.
Currently, StartRound has a menu (incl Move), but OperatingRound hasn't,
so it needs the Undo/Redo as buttons.

> At this point, it doesn't *need* to be fixed right away. We can simply
> disable it if there are enough other things that have changed to merit
> a release.

Indeed. I don't have strong feelings about how the final UI should
incorporate all possible user actions, but I tend to prefer an
approach where normal game actions are executed via buttons, 
and exceptional actions via menu options. 
That would favour putting Undo/Redo into the menu in all screens. 

Erik.

Re: [Rails-devel] Fixes & sorting

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

On 6/24/07, Erik Vos <eri...@hc...> wrote:
> > > > Ahhh...   how about we relabel it as "Master Undo (for testing)" ?
> > >
> > > Hmm, isn't that a bit longish?
> > > I was inspired by the vi commands that get a forcing character when
> > > suffixed with a !, for instance q! forces quit where q doesn't.
> > > I agree that some explanation is needed, perhaps a tooltip?
> > >
> >
> >
> > A tooltip would help, but in general having two menu options named the
> > same thing is going to be confusing.
> >
> > I don't really see a problem with a long menu option. We're not
> > limited for space there.
>
> Actually, I meant that the appearance of two options is temporary.
> ultimately, I think there would be only one undo option (labelled just
> "Undo"),
> and it would depend on the user's role (player or Master/Moderator) what
> its meaning would be.
>
s> For now I suppose we have two ways in which the program can be used:
>
> 1. "Hotseat", which (if I'm right) means that players take turns behind one
> screen.
> In that case, the (restricted) player undo would apply.
>
> 2. Moderator, in which case one person replays or moderates a game.
> In this case the unrestricted version would apply.
>
> What about adding a startup option (two radio buttons?)
> to select between these two usages? Then the "Undo!" could go.
>

Here are some other ways we could do it:

1) We could add a new temporary drop-down menu for testing new
functionality, and just enable/disable it this new menu with a
"development mode" startup option.

2) We can move the "player undo" back onto the game status window,
next to the Done button.  Then rename the Move menu to something like
"Moderator", so that the Undo that's in there is more clearly a
"Moderator Undo"



I like #1 because then we can add anything in there without worrying
too much about choosing a permanent position within the UI for it.
This also allows us to have these potentially confusing UI elements
disabled by default when we ship out new JARs.

I like #2 because it creates a clear differentiator that may be useful
for other features and could be a less temporary (more permanent) way
of presenting that feature.



At this point, it doesn't *need* to be fixed right away. We can simply
disable it if there are enough other things that have changed to merit
a release.


---Brett.

Re: [Rails-devel] Fixes & sorting

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

> > > Ahhh...   how about we relabel it as "Master Undo (for testing)" ?
> >
> > Hmm, isn't that a bit longish?
> > I was inspired by the vi commands that get a forcing character when
> > suffixed with a !, for instance q! forces quit where q doesn't.
> > I agree that some explanation is needed, perhaps a tooltip?
> >
> 
> 
> A tooltip would help, but in general having two menu options named the
> same thing is going to be confusing.
> 
> I don't really see a problem with a long menu option. We're not
> limited for space there.

Actually, I meant that the appearance of two options is temporary.
ultimately, I think there would be only one undo option (labelled just
"Undo"),
and it would depend on the user's role (player or Master/Moderator) what 
its meaning would be.

For now I suppose we have two ways in which the program can be used:

1. "Hotseat", which (if I'm right) means that players take turns behind one
screen.
In that case, the (restricted) player undo would apply.

2. Moderator, in which case one person replays or moderates a game. 
In this case the unrestricted version would apply.

What about adding a startup option (two radio buttons?)
to select between these two usages? Then the "Undo!" could go.

Erik.

Re: [Rails-devel] Fixes & sorting

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

On 6/24/07, Erik Vos <eri...@hc...> wrote:
> > On 6/23/07, Erik Vos <eri...@hc...> wrote:
> > > > So...  first question I have is in the Game Status
> > window, in the Move
> > > > menu, why are there two undo options?  There's "Undo" and "Undo!".
> > >
> > > The idea is that ultimately players will only be able to
> > > undo their own moves, but the game master will be able to
> > undo everything.
> > > So the whole undo stack is kept, but players can only move between
> > > certain boundaries.
> > > Undo! simulates this master command; for now it is there
> > mainly for testing.
> > > Don't expect it to work everywhere yet.
> > >
> >
> > Ahhh...   how about we relabel it as "Master Undo (for testing)" ?
>
> Hmm, isn't that a bit longish?
> I was inspired by the vi commands that get a forcing character when
> suffixed with a !, for instance q! forces quit where q doesn't.
> I agree that some explanation is needed, perhaps a tooltip?
>


A tooltip would help, but in general having two menu options named the
same thing is going to be confusing.

I don't really see a problem with a long menu option. We're not
limited for space there.


> > > > Last... it looks like there's an issue with
> > Util.getStreamForFile().
> > > > It's not finding any of the images for me.  I'm going to
> > try to debug
> > > > this.
> > >
> > > I have wrestled with that as well. I think the fix was to
> > put all images
> > > in the Rails jar file. Finding property and image files
> > clearly still needs
> > > work.
> > >
> >
> > I found the problem.   there's a leading forward slash on the path
> > name.  it needs to be removed.
>
> Ah, yes, that is what happens if tile.root_directory does not have
> a value in my.properties. I have now made sure that the slash is only
> inserted if that property exists and is not empty.
>

Excellent.   That sounds like a better fix than the one I had come up with.


---Brett

Re: [Rails-devel] Fixes & sorting

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

> On 6/23/07, Erik Vos <eri...@hc...> wrote:
> > > So...  first question I have is in the Game Status 
> window, in the Move
> > > menu, why are there two undo options?  There's "Undo" and "Undo!".
> >
> > The idea is that ultimately players will only be able to
> > undo their own moves, but the game master will be able to 
> undo everything.
> > So the whole undo stack is kept, but players can only move between
> > certain boundaries.
> > Undo! simulates this master command; for now it is there 
> mainly for testing.
> > Don't expect it to work everywhere yet.
> >
> 
> Ahhh...   how about we relabel it as "Master Undo (for testing)" ?

Hmm, isn't that a bit longish? 
I was inspired by the vi commands that get a forcing character when
suffixed with a !, for instance q! forces quit where q doesn't.
I agree that some explanation is needed, perhaps a tooltip?

> > > Last... it looks like there's an issue with 
> Util.getStreamForFile().
> > > It's not finding any of the images for me.  I'm going to 
> try to debug
> > > this.
> >
> > I have wrestled with that as well. I think the fix was to 
> put all images
> > in the Rails jar file. Finding property and image files 
> clearly still needs
> > work.
> >
> 
> I found the problem.   there's a leading forward slash on the path
> name.  it needs to be removed.

Ah, yes, that is what happens if tile.root_directory does not have
a value in my.properties. I have now made sure that the slash is only
inserted if that property exists and is not empty.

Erik.