rails-devel — List for discussion of Rails development

Re: [Rails-devel] Game Options

[John A. T. <ja...@ja...>]

Brett Lentz wrote:
> Incorrect. Colossus supports a fairly large number of variants and
> dynamically updates their game options window based on the variant. Try
> playing some of the 9 or 12 player variants that even use an alternate
> master board.
>   
I think of that like selecting options within the game.  Ie, optional 6 
trains or unlimited diesels are variants for 1830.
> More to the point, all of the games are examples that allow the user to
> configure their game options in any order they choose and then starting
> a new game is what actually initializes the game engine.
>   
My point is that when I sit down to play a game, the first thing I 
decide is which game I want to play, and then I decide which options I 
want in that game.  You don't get some players together FTF and decide 
"ok, we want to play with optional 6 trains" then figure out which game 
you want to play that has that rule -- I don't see any reason that 
playing it in Rails should be any different.  Now you may want an easy 
way to change the selection of the game, but to me that just seems like 
going back a step to select a different game and then you redo your 
options starting with the default of the new game.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Game Options

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

> > Take a look at Simtex's 1830 game and how it's UI operates.
> >
> > Every single game allows the user to freely navigate the 
> game's setup
> > window(s) without starting up a new game or locking them 
> into a specific
> > way of interacting with the setup options.
> 
> That is because you have already selected which game you are 
> going to play 
> by running the app.  To start a different game, you exit and 
> start over 
> with a different app.  Rails is adding another level of 
> selection above 
> that, which is selecting the game to play.

Exactly. 
Because of this, looking at other games isn't very relevant here.

Logically, we have three steps in game setup:

1. Game selection.

2. Game preparation (or configuration).

3. Game initialisation.

Each step requires different configuration files:
1: games.properties
2: first part of Game.xml.
3: rest of Game.xml and all other XML files.
Steps 1 and 2 require player input, step 3 runs silently behind the scenes.

In the current situation, we have somewhat mixed up 1 and 2,
because player entry is done in step 1, where we don't know
yet what number of players can be accomodated.
It's gotten slightly more mixed up since my changes of yesterday, 
because now both steps are executed in one window. 
The sequence, however, is still enforced.

We also have a dependency between 2 and 3 because both steps
need Game.xml, but that is not too bad.

In your proposal, steps 1 and 2 would be completely mixed up.
The code will become even more complex.
And we have to read *all* Game.xml files into memory
(remember that the DOM parser reads a whole file before we
get a chance to look at the contents), so these files should
better be small. This definitely would call for the Game.xml split.

In my proposal, we go back to the separate windows 
(as John also proposes), and move player entry to step 2. 
In step 1 we can add other game-independent stuff,
such as language selection, but those things can be done anywhere
(or be preconfigured in my.properties).

In addition the code can be cleaned up somewhat. 
Control of step 2 canbe moved to GameUIManager, 
and I would create a new class for the player/options dialog.
The Game.xml split remains a not-so-important beautification here.

Feel free, though, to try things out your way.
>From next Friday on I'm off for vacation for two weeks, 
so I will (and can) not interfere. 

Erik.

Re: [Rails-devel] Game Options

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

>> Still don't see why it is a problem.
>> Game option setting is part of game initialisation,
>> not of game selection. What is exactly wrong with that?
>> I don't see what we gain by mixing that up.

> Take a look at nearly any other computer game ever made.

How about Colossus?  I believe that's the way variant selection should work
(including the "Load External Variant" capability).

> Take a look at Simtex's 1830 game and how it's UI operates.

I have never liked AH's computer 1830 startup, because if you choose a
player-portrait without knowing any better, it will go ahead and start a
one-player game rather than wait until you're definitively done setting
options.

> Every single game allows the user to freely navigate the game's setup
> window(s) without starting up a new game or locking them into a specific
> way of interacting with the setup options.

Agree.  And the Colossus method agrees also; the 1830 method doesn't.

Re: [Rails-devel] Game Options

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

On Fri, 2007-08-03 at 18:49 -0400, John A. Tamplin wrote:
> On Fri, 3 Aug 2007, Brett Lentz wrote:
> 
> > Take a look at nearly any other computer game ever made.
> >
> > Take a look at Simtex's 1830 game and how it's UI operates.
> >
> > Every single game allows the user to freely navigate the game's setup
> > window(s) without starting up a new game or locking them into a specific
> > way of interacting with the setup options.
> 
> That is because you have already selected which game you are going to play 
> by running the app.  To start a different game, you exit and start over 
> with a different app.  Rails is adding another level of selection above 
> that, which is selecting the game to play.
> 

I think this is an issue of semantics than an actual design concern.

We aren't switching between several different game engines with several
different ways of storing and retrieving their data.

We've got a single game engine, and a single data representation. 

The only real problem is one that we've known already exists: we've
chosen to prioritize a quick design and a working codebase over haggling
over everyone's pet ideal designs and having no codebase.

The current design is now showing a weak point which requires us to
refactor this area of our code.

We knew this was coming. Now, it's just a matter of figuring out a
better design and implementing it. 


> > MegaMek (Java Battletech): http://megamek.sourceforge.net/
> > Java Blood Bowl: http://home.austin.rr.com/javabbowl/
> > Colossus (Java Titan): http://colossus.sourceforge.net/
> > VASL ( Java Advanced Squad Leader): http://www.vasl.org/
> >
> > None of these have this kind of a restriction on when or how game
> > options are selected.
> 
> None of them allow you to play different games either (at least MegaMek or 
> Colossus).
> 

Incorrect. Colossus supports a fairly large number of variants and
dynamically updates their game options window based on the variant. Try
playing some of the 9 or 12 player variants that even use an alternate
master board.

More to the point, all of the games are examples that allow the user to
configure their game options in any order they choose and then starting
a new game is what actually initializes the game engine.


 ---Brett.


There are two ways to write error-free programs; only the third one works.

Re: [Rails-devel] Game Options

[John A. T. <ja...@ja...>]

On Fri, 3 Aug 2007, Brett Lentz wrote:

> Take a look at nearly any other computer game ever made.
>
> Take a look at Simtex's 1830 game and how it's UI operates.
>
> Every single game allows the user to freely navigate the game's setup
> window(s) without starting up a new game or locking them into a specific
> way of interacting with the setup options.

That is because you have already selected which game you are going to play 
by running the app.  To start a different game, you exit and start over 
with a different app.  Rails is adding another level of selection above 
that, which is selecting the game to play.

Personally, I would want to say start a game from the list, and it pops up 
a dialog where I select the parameters for the game, and when I finish 
that dialog the game begins.

> MegaMek (Java Battletech): http://megamek.sourceforge.net/
> Java Blood Bowl: http://home.austin.rr.com/javabbowl/
> Colossus (Java Titan): http://colossus.sourceforge.net/
> VASL ( Java Advanced Squad Leader): http://www.vasl.org/
>
> None of these have this kind of a restriction on when or how game
> options are selected.

None of them allow you to play different games either (at least MegaMek or 
Colossus).

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Game Options

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

On Fri, 2007-08-03 at 23:52 +0200, Erik Vos wrote:
> > > It just occurs to me, that as things currently work, once 
> > the Game.xml of
> > > one game has been parsed, there is no way back. The game 
> > has been started.
> > > Options setting can only postpone finishing initialisation 
> > of that one game,
> > > 
> > > but not revert it.
> > > 
> > 
> > 
> > Yep, that's the problem I'm talking about.
> 
> Still don't see why it is a problem.
> Game option setting is part of game initialisation,
> not of game selection. What is exactly wrong with that?
> I don't see what we gain by mixing that up.
> 


Take a look at nearly any other computer game ever made.

Take a look at Simtex's 1830 game and how it's UI operates.

Every single game allows the user to freely navigate the game's setup
window(s) without starting up a new game or locking them into a specific
way of interacting with the setup options.




> > I do agree that is a simpler way of getting some of the things I want
> > without needing to rework the initialization code much.
> > 
> > However, doing that would cause a couple of different issues. Adding
> > more XML files means blurring the definitions of what information goes
> > into each file, which is a potential headache for managability.
> 
> On the contrary: it is cleaning that up. At least, if you really
> want game option setting to move from game initialisation to
> game selection, which is what I understand you are trying to do.
> Sorry if I am misunderstanding that.
> 
> 

I still don't think you fully understand what I'm talking about.

Have a look at the UI for these games. Study their UI and I think you'll
see what I'm talking about:

MegaMek (Java Battletech): http://megamek.sourceforge.net/
Java Blood Bowl: http://home.austin.rr.com/javabbowl/
Colossus (Java Titan): http://colossus.sourceforge.net/
VASL ( Java Advanced Squad Leader): http://www.vasl.org/


None of these have this kind of a restriction on when or how game
options are selected.


> > Also,
> > this forces us to create a UI that works around this problem to the
> > detriment of usability. And finally, it doesn't really solve the
> > underlying problem, it just means that when we do get around to fixing
> > this problem, we've got a much larger amount of code that is 
> > impacted by
> > the change.
> 
> As said, I don't see the usability problem with having the logical
> distinction
> between game selection and game initialisation being reflected
> in the sequence in which we let players set up a game.
>  
> > I think that in this case, it would be much better to work on solving
> > this problem before it gets any worse.
> > 
> > I'm going to start looking at what it will take to start 
> > separating the
> > game engine from the data loading.
> 
> Not sure what you mean. All of the base classes in the game engine
> parse their own part of the XML, so how can that be separated?

One option is to take a similar idea as the class loader and apply it to
property loading. So that the game engine requests a property from the
loader, and the loader takes care of actually fetching that value. 


> They have to: some of the XML structure is class-dependent, and many classes
> are
> themselves specified in the XML, so the data and engine are very intimately
> intertwined.
> This has to be so, if we want to retain the flexibility to implement
> multiple games, possibly using different classes needing different XML
> structures
> to initialise themselves.
> 


This doesn't mean that the engine must do the reading and parsing of XML
itself. This just means that the engine requires this data from whatever
set of classes loads this data.


> IMHO, all you need to do is to separate the game engine + its data loading
> from the data needed before start-up (the options - in your concept). 
> In other words, split Game.xml.
> 
> We do have a separation between reading and parsing, though,
> because we use a DOM parser.
> The DOM parser reads all of Game.xml into memory, 
> but parsing must now stop after getting the game options. 
> This was needed for our recent juggling with game options,
> and because of that, the code has been cluttered somewhat. 
> Splitting Game.xml would help cleaning that up.
> 
> Not sure if we aren't talking past each other....
> Not sure either if the twain will ever meet....


I suspect that part of the difficulty is that after dealing with the
class loader issues, I've gotten a little bit more knowledgeable about a
different (better?) way of handling loading this data.  So, it's now
easier for me to see the source of the issues.

Also, consider this...   what happens when we want to handle network
play?  In order to distribute consistent information about the game and
minimize the risk of cheating, we're going to need a client app that's
able to receive the game data from the server.

We can't do this kind of client-server communication if the game engine
is relying on loading and parsing these files on its own.


 ---Brett.


I stick my neck out for nobody.
		-- Humphrey Bogart, "Casablanca"

Re: [Rails-devel] Game Options

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

I have submitted a new version of Game Options handling, which is now, 
for good or bad, put into the same window as the initial stuff.
The now redundant OK button has been removed.

As said before: once Options is pressed and the options are loaded, 
the game has started.
Therefore, the Options and Load Game buttons are disabled at that point.
Also, changing players or the selected game has no effect from that point.
That's how it is and has to be now.
Whether it will stay so is another story.

> > It just occurs to me, that as things currently work, once 
> the Game.xml of
> > one game has been parsed, there is no way back. The game 
> has been started.
> > Options setting can only postpone finishing initialisation 
> of that one game,
> > 
> > but not revert it.
> > 
> 
> 
> Yep, that's the problem I'm talking about.

Still don't see why it is a problem.
Game option setting is part of game initialisation,
not of game selection. What is exactly wrong with that?
I don't see what we gain by mixing that up.

 
> > To change that, quite some rework may be needed. 
> > Of course it can be done, but I can't currently assess what 
> it would take.
> > 
> > And that is why I think we should separate the simple game options
> > from the rest of the whole XML. The game options in 
> Game.xml can then be
> > read
> > without firing off the whole irreversible Components parsing.
> > That would make the approach that you favour much easier.
> > 
> 
> 
> I do agree that is a simpler way of getting some of the things I want
> without needing to rework the initialization code much.
> 
> However, doing that would cause a couple of different issues. Adding
> more XML files means blurring the definitions of what information goes
> into each file, which is a potential headache for managability.

On the contrary: it is cleaning that up. At least, if you really
want game option setting to move from game initialisation to
game selection, which is what I understand you are trying to do.
Sorry if I am misunderstanding that.


> Also,
> this forces us to create a UI that works around this problem to the
> detriment of usability. And finally, it doesn't really solve the
> underlying problem, it just means that when we do get around to fixing
> this problem, we've got a much larger amount of code that is 
> impacted by
> the change.

As said, I don't see the usability problem with having the logical
distinction
between game selection and game initialisation being reflected
in the sequence in which we let players set up a game.
 
> I think that in this case, it would be much better to work on solving
> this problem before it gets any worse.
> 
> I'm going to start looking at what it will take to start 
> separating the
> game engine from the data loading.

Not sure what you mean. All of the base classes in the game engine
parse their own part of the XML, so how can that be separated?
They have to: some of the XML structure is class-dependent, and many classes
are
themselves specified in the XML, so the data and engine are very intimately
intertwined.
This has to be so, if we want to retain the flexibility to implement
multiple games, possibly using different classes needing different XML
structures
to initialise themselves.

IMHO, all you need to do is to separate the game engine + its data loading
from the data needed before start-up (the options - in your concept). 
In other words, split Game.xml.

We do have a separation between reading and parsing, though,
because we use a DOM parser.
The DOM parser reads all of Game.xml into memory, 
but parsing must now stop after getting the game options. 
This was needed for our recent juggling with game options,
and because of that, the code has been cluttered somewhat. 
Splitting Game.xml would help cleaning that up.

Not sure if we aren't talking past each other....
Not sure either if the twain will ever meet....

Erik.

Re: [Rails-devel] Game Options

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

On Fri, 2007-08-03 at 21:09 +0200, Erik Vos wrote:
> It just occurs to me, that as things currently work, once the Game.xml of
> one game has been parsed, there is no way back. The game has been started.
> Options setting can only postpone finishing initialisation of that one game,
> 
> but not revert it.
> 


Yep, that's the problem I'm talking about.


> To change that, quite some rework may be needed. 
> Of course it can be done, but I can't currently assess what it would take.
> 
> And that is why I think we should separate the simple game options
> from the rest of the whole XML. The game options in Game.xml can then be
> read
> without firing off the whole irreversible Components parsing.
> That would make the approach that you favour much easier.
> 


I do agree that is a simpler way of getting some of the things I want
without needing to rework the initialization code much.

However, doing that would cause a couple of different issues. Adding
more XML files means blurring the definitions of what information goes
into each file, which is a potential headache for managability. Also,
this forces us to create a UI that works around this problem to the
detriment of usability. And finally, it doesn't really solve the
underlying problem, it just means that when we do get around to fixing
this problem, we've got a much larger amount of code that is impacted by
the change.

I think that in this case, it would be much better to work on solving
this problem before it gets any worse.

I'm going to start looking at what it will take to start separating the
game engine from the data loading.


 ---Brett.


Paranoia is simply an optimistic outlook on life.

Re: [Rails-devel] Mailing lists

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

On Fri, 2007-08-03 at 14:11 -0500, Chris Shaffer wrote:
> Is there an announcements-style list to which I could subscribe, to
> learn about new releases but bypass the nitty-gritty programming
> discussions?
> 
> -- 
> Chris 


There isn't one currently.   Though, it would be easy to create if
there's enough interest.

I do post release announcements to the 18xx-softdev mailing list and,
depending on the significance of the release, also the 18xx mailing
list.


 ---Brett.


Disease can be cured; fate is incurable.
		-- Chinese proverb

[Rails-devel] Mailing lists

[Chris S. <chr...@gm...>]

Is there an announcements-style list to which I could subscribe, to learn
about new releases but bypass the nitty-gritty programming discussions?

-- 
Chris

Re: [Rails-devel] Game Options

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

On Fri, 2007-08-03 at 20:39 +0200, Erik Vos wrote:
> > > > This would also allow us to add a property to define the number of
> > > > minimum and maximum players, and have the Options() 
> > dialog dynamically
> > > > add or subtract name boxes based on this data.
> > > 
> > > In that case, the game selection should precede player entry.
> > > 
> > 
> > 
> > No. Starting a game must not happen in forced steps. This is 
> > simply not
> > an acceptable approach.
> 
> I would say that things that are game-dependent can't be displayed
> before a game is selected...
> 
> That refers to min/max # of players, game options,
> and other things that you are talking about.
> 

That's one possibility, but even with reading the game files on game
selection, we can still default to having a selected game on startup and
reading that game's information.

The other possibility is simply reading the Game.xml for all available
games as defined by game.properties. 

Note that I say read, and not parse. There's nothing that requires us to
actually use all of the data that's available to us.

Either way we do it (read selected or read all), we still must divorce
reading and parsing the XML from actually setting up the game objects. 

> ----
> 
> Well, while you are thinking about how the UI should really look like and
> work,
> I'll finish the basic version I'm doing now, and then leave it to you.
> 
> Just a warning that the order in which things are presented to 
> the game engine *is* critical.


And that's essentially the issue I'm raising.  Right now the game engine
dictates when the XML is read and parsed. This is forcing us to bend the
UI to the game engine's processing. This is causing us to sacrifice the
usability of the UI for the inflexibility of the game engine.

This trade-off makes no sense at all.

While the game engine may need certain data in a specific order, that
doesn't mean that retrieving the data from the XML must happen in that
order. All it means is that the data must be available when the game
engine needs it.

There's no good reason why we can't load more of that data first so that
the UI can use it and present it in a user-friendly way, and then pass
the data to the game engine in the format and order the game engine
requires.



 ---Brett.


When the least they could do to you was everything, then the most
they could do to you suddenly held no terror.
(Small Gods)

Re: [Rails-devel] Game Options

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

It just occurs to me, that as things currently work, once the Game.xml of
one game has been parsed, there is no way back. The game has been started.
Options setting can only postpone finishing initialisation of that one game,

but not revert it.

To change that, quite some rework may be needed. 
Of course it can be done, but I can't currently assess what it would take.

And that is why I think we should separate the simple game options
from the rest of the whole XML. The game options in Game.xml can then be
read
without firing off the whole irreversible Components parsing.
That would make the approach that you favour much easier.

Erik.

> > > > This would also allow us to add a property to define 
> the number of
> > > > minimum and maximum players, and have the Options() 
> > dialog dynamically
> > > > add or subtract name boxes based on this data.
> > > 
> > > In that case, the game selection should precede player entry.
> > > 
> > 
> > 
> > No. Starting a game must not happen in forced steps. This is 
> > simply not
> > an acceptable approach.
> 
> I would say that things that are game-dependent can't be displayed
> before a game is selected...
> 
> That refers to min/max # of players, game options,
> and other things that you are talking about.
> 
> ----
> 
> Well, while you are thinking about how the UI should really 
> look like and
> work,
> I'll finish the basic version I'm doing now, and then leave it to you.
> 
> Just a warning that the order in which things are presented to 
> the game engine *is* critical.

Re: [Rails-devel] Game Options

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

> > > This would also allow us to add a property to define the number of
> > > minimum and maximum players, and have the Options() 
> dialog dynamically
> > > add or subtract name boxes based on this data.
> > 
> > In that case, the game selection should precede player entry.
> > 
> 
> 
> No. Starting a game must not happen in forced steps. This is 
> simply not
> an acceptable approach.

I would say that things that are game-dependent can't be displayed
before a game is selected...

That refers to min/max # of players, game options,
and other things that you are talking about.

----

Well, while you are thinking about how the UI should really look like and
work,
I'll finish the basic version I'm doing now, and then leave it to you.

Just a warning that the order in which things are presented to 
the game engine *is* critical.

Erik.

Re: [Rails-devel] Game Options

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

On Fri, 2007-08-03 at 19:32 +0200, Erik Vos wrote:

> > I think we might be able to get away with just creating an array of
> > ComponentManagers, and read all of the Game.xmls on startup. 
> > This should
> > give us all of the information we need to present the inital game
> > information and game variant options. 
> 
> Yes, I was thinking along the same lines. 
> My suggestion is to split Game.xml into a smaller Game.xml 
> that only has the startup options, and a Components.xml
> that contains all the rest. Only Game.xml is needed to
> find out about variants and such.
> 

I'm not sure adding more files really buys us much. One way or another,
we're going to need to read files for each game.

I think that we have the start of a good system:

game.properties defines what games are available, and gives a basic
description of how functional each game is.

Game.xml defines all of the basic information about each game. Much of
this information we could expose in the startup dialog as additional
game information for users that aren't familiar with every game.

It could be handy to display information such as starting player wallet
values, and the starting bank value.

So, splitting this into another file would deprive us of this ability or
force us to add redundant information into multiple files.

> > This would also allow us to add a property to define the number of
> > minimum and maximum players, and have the Options() dialog dynamically
> > add or subtract name boxes based on this data.
> 
> In that case, the game selection should precede player entry.
> 


No. Starting a game must not happen in forced steps. This is simply not
an acceptable approach.

We need to be able to load some basic info about each game, then present
the user with a single UI for them to select a game, select variants,
enter player names, and do it in any order they choose. Providing
information about each game is helpful, but is a lower priority issue
(for now).

The only thing we should be doing is disallowing them from clicking New
Game until the minimum requirements for each game are met. After that,
the user should be free to navigate the UI any way that suits them.


 ---Brett.


Teamwork is essential -- it allows you to blame someone else.

Re: [Rails-devel] Game Options

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

> > OK, I'll try to change it that way one of these days.

In fact I have started today.

> > First the functionality, then the beautification.
> 
> 
> Hmmm...  I just took a deeper look at this. I now have a better
> understanding of why you took this approach.
> 
> It looks like we've got some pretty fundamental design flaws in our
> initialization code.
> 
> It seems that in order to get the variant options, we need to 
> parse the
> game XML. We don't parse the game XML until we start a new game.
> 
> We really don't want to start a new game just to read which variants
> exist, if any.
> 
> So, it appears that we may need to refactor our initialization code a
> bit, or create a new interface to loading the XML properties.

In any case, part of the code in Options should move to GameUIManager.
But that can be done after we have found a good concept. Let's do that
first.

> I think we might be able to get away with just creating an array of
> ComponentManagers, and read all of the Game.xmls on startup. 
> This should
> give us all of the information we need to present the inital game
> information and game variant options. 

Yes, I was thinking along the same lines. 
My suggestion is to split Game.xml into a smaller Game.xml 
that only has the startup options, and a Components.xml
that contains all the rest. Only Game.xml is needed to
find out about variants and such.

> This would also allow us to add a property to define the number of
> minimum and maximum players, and have the Options() dialog dynamically
> add or subtract name boxes based on this data.

In that case, the game selection should precede player entry.

> Then, when the New Game button is clicked, we can just choose 
> the proper
> ComponentManager from the array, and discard the rest.

In my proposal: then start loading Components.xml.

Erik.

Re: [Rails-devel] Game Options

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

On Thu, 2007-08-02 at 23:33 +0200, Erik Vos wrote:
> > 
> > We don't start the game with OK because the user may not be finished
> > setting up their game. If I want to select my game options, then enter
> > in the players names, that needs to be just as valid as 
> > entering player
> > names then selecting game options.
> > 
> > This is why I'd prefer to keep these things all in the same window.
> > Changing the dialog (or having an extra dialog) isn't at all necessary
> > and causes more problems with the UI than it solves.
> 
> OK, I'll try to change it that way one of these days.
> 
> First the functionality, then the beautification.


Hmmm...  I just took a deeper look at this. I now have a better
understanding of why you took this approach.

It looks like we've got some pretty fundamental design flaws in our
initialization code.

It seems that in order to get the variant options, we need to parse the
game XML. We don't parse the game XML until we start a new game.

We really don't want to start a new game just to read which variants
exist, if any.

So, it appears that we may need to refactor our initialization code a
bit, or create a new interface to loading the XML properties.

I think we might be able to get away with just creating an array of
ComponentManagers, and read all of the Game.xmls on startup. This should
give us all of the information we need to present the inital game
information and game variant options. 

This would also allow us to add a property to define the number of
minimum and maximum players, and have the Options() dialog dynamically
add or subtract name boxes based on this data.

Then, when the New Game button is clicked, we can just choose the proper
ComponentManager from the array, and discard the rest.





 ---Brett.


The last time I saw him he was walking down Lover's Lane holding his own hand.
		-- Fred Allen

Re: [Rails-devel] Game Options

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

On Thu, 2007-08-02 at 23:33 +0200, Erik Vos wrote:
> > > OK, I had missed that point: you want a user allow to skip 
> > the game options
> > > part.
> > > Fair enough.
> > > 
> > 
> > 
> > Yes.  They're called "options" because they're optional. Otherwise
> > they'd be called "requirements" or "dependencies".  ;-)
>  
> Hmm, yes, so I guess you'll understand why I have always found "Options"
> a somewhat confusing name for that whole class...  :-)
>  


Good point.  Perhaps we should refactor that class name to something a
little more meaningful. 



> > > 
> > > OK, although the last to items can be skipped IMO: why not 
> > let OK start the
> > > game?
> > 
> > 
> > We don't start the game with OK because the user may not be finished
> > setting up their game. If I want to select my game options, then enter
> > in the players names, that needs to be just as valid as 
> > entering player
> > names then selecting game options.
> > 
> > This is why I'd prefer to keep these things all in the same window.
> > Changing the dialog (or having an extra dialog) isn't at all necessary
> > and causes more problems with the UI than it solves.
> 
> OK, I'll try to change it that way one of these days.
> 
> First the functionality, then the beautification.


That's fine.  If I get a chance, I can also do it myself. :-)



 ---Brett.


I'd horsewhip you if I had a horse.
		-- Groucho Marx

Re: [Rails-devel] Game Options

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

> > OK, I had missed that point: you want a user allow to skip 
> the game options
> > part.
> > Fair enough.
> > 
> 
> 
> Yes.  They're called "options" because they're optional. Otherwise
> they'd be called "requirements" or "dependencies".  ;-)
 
Hmm, yes, so I guess you'll understand why I have always found "Options"
a somewhat confusing name for that whole class...  :-)
 
> > > This requires two separate UI paths:
> > > 
> > > First: Options() presented -> User hits New Game button 
> -> New game is
> > > started, code just assumes no optional 6 train (i.e. the 
> default value
> > > is used).
> > > 
> > > Second: Options() presented -> User clicks Variants 
> button -> Variants
> > > dialog is presented -> User selects variant options and hits an OK
> > > button -> User is returned to Options() -> User clicks 
> New Game button
> > > -> New Game starts.
> > 
> > OK, although the last to items can be skipped IMO: why not 
> let OK start the
> > game?
> 
> 
> We don't start the game with OK because the user may not be finished
> setting up their game. If I want to select my game options, then enter
> in the players names, that needs to be just as valid as 
> entering player
> names then selecting game options.
> 
> This is why I'd prefer to keep these things all in the same window.
> Changing the dialog (or having an extra dialog) isn't at all necessary
> and causes more problems with the UI than it solves.

OK, I'll try to change it that way one of these days.

First the functionality, then the beautification.

Erik.

Re: [Rails-devel] New ClassLoader

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

> > Just a question: does this also allow reading from the Rails.jar?
> >  
> 
> 
> Yes, it does.  Over the last week, I've had a bit of a crash course in
> how Java locates data.
> 
> The whole idea is that Java wants you to avoid using anything specific
> to the underlying machine until the last possible moment. So, 
> everything
> that requires data from external resources (i.e. data files, images,
> etc.) needs to use a class loader to search for those resources. It's
> the class loader's job to figure out what resources are available, and
> where they are using generic path identifiers.
 
Well, there you're ahead of me then. I've had similar problems
every now and then. Great that you have fixed that now.


Erik.

Re: [Rails-devel] New ClassLoader

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

On Thu, 2007-08-02 at 21:30 +0200, Erik Vos wrote:
> > I've just committed some fairly big changes.
> > 
> > I've pulled in the custom Class Loader from Colossus, and then tweaked
> > it a bunch.
> > 
> > This begins to clear up a bunch of problems I've been having getting
> > Rails to run under JNLP. These problems are mainly our depending on
> > using the local file system. While I'm not quite done yet, this is
> > certainly a step in the right direction.
> > 
> > Additionally, I've deprecated the Util.getStreamFromFile() method.
> > Please use ResourceLoader.getInputStream() instead.
> 
> Just a question: does this also allow reading from the Rails.jar?
>  


Yes, it does.  Over the last week, I've had a bit of a crash course in
how Java locates data.

The whole idea is that Java wants you to avoid using anything specific
to the underlying machine until the last possible moment. So, everything
that requires data from external resources (i.e. data files, images,
etc.) needs to use a class loader to search for those resources. It's
the class loader's job to figure out what resources are available, and
where they are using generic path identifiers.

At first I was considering writing a whole new class loader for us, but
as I was reviewing a few different projects, the Colossus class loader
looked very close to what we needed, so I used it as a base.


> > For now, I've updated the relevant areas to use the new 
> > method signature
> > so that things still compile and function. Next, I'll be removing some
> > of the redundancy this new class creates.
> > 
> > Lastly, thanks to the addition of the game.properties file, 
> > I've removed
> > reading the local file system to build the game list.
> 
> The old version would not have shown a game listed in games.properties,
> if the related directory did not actually exist. Now I'm getting
> several Exceptions on the console if such a non-existing entry is chosen.
> No big deal, but IMO some check should be in place.
> 


Yes, this is a necessity unfortunately. 

The big limitation to being platform agnostic is that we can't really
say "scan this location for stuff I need".  So, it was really fortunate
that you had just added in the game.properties file. It's the perfect
substitute for directory scanning, and simplifies the code quite a bit.

The downside is now the game.properties file must be kept synchronized
with the data/ directory entries.



> One real gripe though: you have also changed the stand-alone utilities
> ConvertTilesXML and MakeGameTileSets.
> These classes are not really part of the game. 
> Running these development aids now requires adding log4j.jar to the
> classpath,
> and standing the resulting warnings about not having configured log4j
> appenders.
> 

Oops. I didn't notice that. I just updated them to use the new
interface. I didn't really think about the additional import statements
that ResourceLoader uses.


> I think these utilities do not belong in package rails.util at all.

Agreed.

> In fact I vaguely remember that I had them originally in a separate 
> tools package. I'm going to put the original versions back there.
> If you don't want them there, I can keep these versions local.
> 
> Erik.

That's fine.

 ---Brett.


Excellent day for putting Slinkies on an escalator.

Re: [Rails-devel] Game Options

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

On Thu, 2007-08-02 at 21:15 +0200, Erik Vos wrote:
> > > > 1. A new section (JPanel) is added to the existing 
> > Options dialog, and
> > > > shows any available variants, and is not visible if no 
> > variants are
> > > > found.
> > > 
> > > This is about what happens, except that (1) the original 
> > contents of that
> > > window have been removed 
> > > (the alternative being to disable everything before adding 
> > the new stuff)
> > > and (2) it is moved 200x200 pixels to make it somewhat 
> > better accessible.
> > > And, yes, it is briefly out of sight.
> > > It should be easy to tweak it your way - go ahead, I would say.
> > > 
> > 
> > You're misunderstanding my meaning. This isn't at all what happens. 
> > 
> > By new JPanel, I'm meaning a new JPanel within Options(), 
> > this does not
> > mean a modal popup dialog.
> 
> This is what happens (have a look at the code), although it does not seem
> so....
> But I understand that you want the rest of the Options window
> remain visible, well, that is easy enough to do:
> remove setVisible(false), and remove getContentPane().removeAll().
> Well, it may be a bit more work because I have also used a different layout
> manager,
> so it may not be that easy...
>  


Now you're just playing funny semantics games.

Technically, you call getContentPane().removeAll() on the Options
dialog, which removes the current Options UI, and replace it with the
new elements. 

This is effectively the same exact thing as creating a whole new dialog.
The old UI goes away, and the user is presented with a new UI.

I don't care about the technical details of how it works. It's the
user's experience that matters. It's the user experience that is exactly
what I don't want. 

New Game needs to start a new game. No additional questions. No
additional options. New Game must start the game.


> > > > 2. A new button on the Options dialog that then pops up 
> > the variant
> > > > selector dialog.
> > > 
> > > That button already exists: it is the New Game button.
> > > 
> > 
> > Wrong answer.  New Game needs to start a new game *immediately*.
> > 
> > If we're going the button route, then it needs to be a *different*
> > button that shows the variant options. This button needs to 
> > only toggle
> > the variant values, and not be in between the user and starting a new
> > game.
> 
> OK, I had missed that point: you want a user allow to skip the game options
> part.
> Fair enough.
> 


Yes.  They're called "options" because they're optional. Otherwise
they'd be called "requirements" or "dependencies".  ;-)


> > This requires two separate UI paths:
> > 
> > First: Options() presented -> User hits New Game button -> New game is
> > started, code just assumes no optional 6 train (i.e. the default value
> > is used).
> > 
> > Second: Options() presented -> User clicks Variants button -> Variants
> > dialog is presented -> User selects variant options and hits an OK
> > button -> User is returned to Options() -> User clicks New Game button
> > -> New Game starts.
> 
> OK, although the last to items can be skipped IMO: why not let OK start the
> game?


We don't start the game with OK because the user may not be finished
setting up their game. If I want to select my game options, then enter
in the players names, that needs to be just as valid as entering player
names then selecting game options.

This is why I'd prefer to keep these things all in the same window.
Changing the dialog (or having an extra dialog) isn't at all necessary
and causes more problems with the UI than it solves.



 ---Brett.


Two is not equal to three, even for large values of two.

Re: [Rails-devel] Game Options

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

> I hope you will also enable the most important option omitted 
> from AH's
> computer 1830 - unlimited diesels (which Bromley said should 
> be standard).

That was an easy one: Done.

Erik.

Re: [Rails-devel] New ClassLoader

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

> I've just committed some fairly big changes.
> 
> I've pulled in the custom Class Loader from Colossus, and then tweaked
> it a bunch.
> 
> This begins to clear up a bunch of problems I've been having getting
> Rails to run under JNLP. These problems are mainly our depending on
> using the local file system. While I'm not quite done yet, this is
> certainly a step in the right direction.
> 
> Additionally, I've deprecated the Util.getStreamFromFile() method.
> Please use ResourceLoader.getInputStream() instead.

Just a question: does this also allow reading from the Rails.jar?
 
> For now, I've updated the relevant areas to use the new 
> method signature
> so that things still compile and function. Next, I'll be removing some
> of the redundancy this new class creates.
> 
> Lastly, thanks to the addition of the game.properties file, 
> I've removed
> reading the local file system to build the game list.

The old version would not have shown a game listed in games.properties,
if the related directory did not actually exist. Now I'm getting
several Exceptions on the console if such a non-existing entry is chosen.
No big deal, but IMO some check should be in place.

One real gripe though: you have also changed the stand-alone utilities
ConvertTilesXML and MakeGameTileSets.
These classes are not really part of the game. 
Running these development aids now requires adding log4j.jar to the
classpath,
and standing the resulting warnings about not having configured log4j
appenders.

I think these utilities do not belong in package rails.util at all.
In fact I vaguely remember that I had them originally in a separate 
tools package. I'm going to put the original versions back there.
If you don't want them there, I can keep these versions local.

Erik.

Re: [Rails-devel] Game Options

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

> > > 1. A new section (JPanel) is added to the existing 
> Options dialog, and
> > > shows any available variants, and is not visible if no 
> variants are
> > > found.
> > 
> > This is about what happens, except that (1) the original 
> contents of that
> > window have been removed 
> > (the alternative being to disable everything before adding 
> the new stuff)
> > and (2) it is moved 200x200 pixels to make it somewhat 
> better accessible.
> > And, yes, it is briefly out of sight.
> > It should be easy to tweak it your way - go ahead, I would say.
> > 
> 
> You're misunderstanding my meaning. This isn't at all what happens. 
> 
> By new JPanel, I'm meaning a new JPanel within Options(), 
> this does not
> mean a modal popup dialog.

This is what happens (have a look at the code), although it does not seem
so....
But I understand that you want the rest of the Options window
remain visible, well, that is easy enough to do:
remove setVisible(false), and remove getContentPane().removeAll().
Well, it may be a bit more work because I have also used a different layout
manager,
so it may not be that easy...
 
> > > 2. A new button on the Options dialog that then pops up 
> the variant
> > > selector dialog.
> > 
> > That button already exists: it is the New Game button.
> > 
> 
> Wrong answer.  New Game needs to start a new game *immediately*.
> 
> If we're going the button route, then it needs to be a *different*
> button that shows the variant options. This button needs to 
> only toggle
> the variant values, and not be in between the user and starting a new
> game.

OK, I had missed that point: you want a user allow to skip the game options
part.
Fair enough.

> This requires two separate UI paths:
> 
> First: Options() presented -> User hits New Game button -> New game is
> started, code just assumes no optional 6 train (i.e. the default value
> is used).
> 
> Second: Options() presented -> User clicks Variants button -> Variants
> dialog is presented -> User selects variant options and hits an OK
> button -> User is returned to Options() -> User clicks New Game button
> -> New Game starts.

OK, although the last to items can be skipped IMO: why not let OK start the
game?

Erik.

Re: [Rails-devel] Game Options

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

On Thu, 2007-08-02 at 20:36 +0200, Erik Vos wrote:
> > This is exactly the kind of "bad pop-up" that I was talking about a
> > couple of weeks ago.
> > 
> > This needs to somehow be a part of the Options UI. Deciding whether to
> > have an optional 6 train is not a question that's important enough to
> > merit interrupting the start of a game.
> > 
> > There are a couple of ways we can go about this:
> > 
> > 1. A new section (JPanel) is added to the existing Options dialog, and
> > shows any available variants, and is not visible if no variants are
> > found.
> 
> This is about what happens, except that (1) the original contents of that
> window have been removed 
> (the alternative being to disable everything before adding the new stuff)
> and (2) it is moved 200x200 pixels to make it somewhat better accessible.
> And, yes, it is briefly out of sight.
> It should be easy to tweak it your way - go ahead, I would say.
> 

You're misunderstanding my meaning. This isn't at all what happens. 

By new JPanel, I'm meaning a new JPanel within Options(), this does not
mean a modal popup dialog.

> > 2. A new button on the Options dialog that then pops up the variant
> > selector dialog.
> 
> That button already exists: it is the New Game button.
> 

Wrong answer.  New Game needs to start a new game *immediately*.

If we're going the button route, then it needs to be a *different*
button that shows the variant options. This button needs to only toggle
the variant values, and not be in between the user and starting a new
game.

This requires two separate UI paths:

First: Options() presented -> User hits New Game button -> New game is
started, code just assumes no optional 6 train (i.e. the default value
is used).

Second: Options() presented -> User clicks Variants button -> Variants
dialog is presented -> User selects variant options and hits an OK
button -> User is returned to Options() -> User clicks New Game button
-> New Game starts.




 ---Brett.


Darth Vader:
	Commander, tear this ship apart until you've
	found those plans. And bring me the passengers, I
	want them alive!