rails-devel

Re: [Rails-devel] Game Options

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

brett lentz wrote:
> 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.
>   
I'm all for fixing that.  However, it appears you want to go further and 
allow you to set the options before selecting the game, which seems 
backwards and counterintuitive.  What do you do with selected options 
when you change the game?  If you change the game to one that doesn't 
have that same option (or the same value available, such as changing a 
5-player 18GL to 18FL), what do you do?  Do you remember that option if 
they change the game back?
> With the current design, there are so many basic UI things that simply
> aren't possible.
>   
It should be possible to go back and forth until you actually start the 
game.  However, I think there is a clear order of selecting the game 
before selecting the options to play that game with.

-- 
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 8/4/07, John A. Tamplin <ja...@ja...> wrote:
> brett lentz wrote:
> > 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.
> >
> I'm all for fixing that.  However, it appears you want to go further and
> allow you to set the options before selecting the game, which seems
> backwards and counterintuitive.  What do you do with selected options
> when you change the game?  If you change the game to one that doesn't
> have that same option (or the same value available, such as changing a
> 5-player 18GL to 18FL), what do you do?  Do you remember that option if
> they change the game back?


Perhaps this is where I may not be making myself clear enough.

Here's a step by step of what I'm looking for:

1. Jar is executed, startup window is shown.
2. game.properties is read, we find out what games are available.
3. As UI is built, a default game (1830) is set as selected.
4. We read the Game.xml for the selected game, learn the options, and
save the xml data to a cache for use when the game is started
5. As the user selects different games, we repeat step 4 as necessary.
6. As soon as "Start New Game" is clicked, we take the state of the
UI, and feed those values into the game engine to start whatever game
was selected.



> > With the current design, there are so many basic UI things that simply
> > aren't possible.
> >
> It should be possible to go back and forth until you actually start the
> game.  However, I think there is a clear order of selecting the game
> before selecting the options to play that game with.
>

Sure, the initial loading of the options can happen after a game is
selected. We could also just load all of the options for all of the
games on startup.

Either option is viable and gets us access to the data the startup UI needs.


---Brett

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)