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.