This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: variants for all games


Jim Kingdon wrote:
> 
> > However, Stan didn't like the idea, so he removed the code about a
> > year later. He thought we should fix the real problem (the game files)
> > instead of using this ugly hack. We never got around to doing that,
> > though.
> 
> Well, I don't see any record of this in the mailing list archives so I
> don't know what his reasoning was.  I don't think we need to bring
> back the add_more_variants code; I think it is as simple as changing
> "int force_all_variants = FALSE;" to TRUE in read.c.  If the .g file
> mentions the variant anyway, the code seems like it can deal with it.
> 
> It might be better if the .g file can set force_all_variants (with the
> default to TRUE, probably), but I don't really see what the problem
> with having it always TRUE would be.

My memory is full of holes (HSE, Human Spongiform Encephaly, aka mad
nerd disease :-) ), but I think my concern was that it enabled
variants in games for which they didn't make any sense or even
defeated the purpose of the game.  I thought I manually added all the
plausible (to me :-) ) variants to the extant game library at some
later point.

There is a general decision to make here, which is how much control
do you want to give to module authors.  My original theory was that
Xconq is a platform for game development, which means that the game
designer should be able to control exactly what the players see, up
to and including the list of variant options available.  But that's
a pretty high bar to maintain, perhaps higher than is really necessary.

Stan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]