rails-devel

[Rails-devel] Game Options

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

I have committed code to implement a generic Game Options feature.
See the example in 1830/Game.xml, where it is used to allow the 
optional 3rd 6-train. 1830/Game.xml has some comments about the
usage of the new <GameOption> tag.

The existing <Variant> tag (1835) has been replaced by <GameOption> as well.

If a game has any <GameOption> tags, a dialog window will appear to
let the user make the necessary selections (in fact I have reused the
Options window). 
The window contents are automatically generated from all found <GameOption>
tags.

Currently two selection objects can be shown:
- a dropdown list (the default), or
- a checkbox (if a 'type="toggle"' attribute exists in that GameOption).

I have not made any special attempts to make the window look nice,
but it does the job.

The presence in one XML file (Game.xml) of the specification of 
the available game options, and the consumption of their user-assigned
values,
required a split of the game initialisation code in the classes Options  
and GameManager. Now first the GameManager component is parsed,
then the popup is shown, and finally the other components are parsed.

This structure will in a later stage be refactored to fit into the
pattern for all user actions (where PossibleAction objects 
are exchanged between the client and the server part).
But I am a bit tired of that subject now....

The save file structure has changed to contain the game options list.
I have also added a version number to the code and the save files. 
Save files with a different version number than would be created
by the current code are considered incompatible.
So you can throw away any existing save files after you have loaded this
code.

The version number should not change that often, but this time it does....

Erik Vos

Re: [Rails-devel] Game Options

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

Erik Vos wrote:
> I have committed code to implement a generic Game Options feature.
> See the example in 1830/Game.xml, where it is used to allow the 
> optional 3rd 6-train. 1830/Game.xml has some comments about the
> usage of the new <GameOption> tag.

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

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] Game Options

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

On Wed, 2007-08-01 at 23:28 +0200, Erik Vos wrote:
> If a game has any <GameOption> tags, a dialog window will appear to
> let the user make the necessary selections (in fact I have reused the
> Options window). 
> The window contents are automatically generated from all found <GameOption>
> tags.

> Erik Vos


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.

2. A new button on the Options dialog that then pops up the variant
selector dialog.

3. Some other idea that's not immediately apparent to me.



 ---Brett.


Of course he was all in favour of Armageddon in *general* terms.
        -- (Terry Pratchett & Neil Gaiman, Good Omens)

Re: [Rails-devel] Game Options

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

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

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

> 3. Some other idea that's not immediately apparent to me.

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!

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

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

[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

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

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

[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

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

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

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

On 8/4/07, John A. Tamplin <ja...@ja...> wrote:
> 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.
>


And right now, that's not possible. If you get as far as setting the
optional rules, you can't change your mind and go back to select a
different game.

Also, if you notice a typo in someone's name when you're picking the
optional rules, you can't go back and fix it.

Or, if you just want to flip through what optional rules are available
for each game, that's not possible.

With the current design, there are so many basic UI things that simply
aren't possible.


---Brett

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

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

On 8/4/07, Erik Vos <eri...@hc...> wrote:
> > > 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.
>


I completely disagree. See my reply to this statement from John.


> Logically, we have three steps in game setup:
>
> 1. Game selection.
>
> 2. Game preparation (or configuration).
>
> 3. Game initialisation.
>


The code is currently enforcing the distinction between these steps,
but I don't agree that they necessarily need to exist in such a rigid
ordering.

I see it more like this:

1. Game configuration
     a. Game Selection
     b. Player Selection
     c. Game option Selection
2. Game initialization



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


There's no good reason why we can't know this.   We have 1830 selected
by default.  We should be reading it's Game.XML on startup to find out
how many players are allowed.

>
> In your proposal, steps 1 and 2 would be completely mixed up.
> The code will become even more complex.

I don't think that's necessarily true. Right now, there's no evidence
that this will be the case.

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

Not really.  Have you even bothered to check the size of the Game.xml?

Right now, all of the Game.xml files are 3-5kb. Granted, that's
because we haven't populated most of them with everything they'll
need. Even 1830's Game.xml, which is a realistic size, is 5kb.

I don't think that reading even 50 of these things into memory is
going to be all that significant in terms of load time or resource
usage.


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

Please don't consider it interfering. Your efforts continue to be
invaluable. I completely understand that much of this code is
something that you worked very hard on getting to work. You've
invested a lot of time into these sections of the code. I value that
more than I can really articulate.


---Brett

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

[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