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"