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