From: Erik V. <eri...@hc...> - 2007-08-03 17:32:38
|
> > OK, I'll try to change it that way one of these days. In fact I have started today. > > First the functionality, then the beautification. > > > Hmmm... I just took a deeper look at this. I now have a better > understanding of why you took this approach. > > It looks like we've got some pretty fundamental design flaws in our > initialization code. > > It seems that in order to get the variant options, we need to > parse the > game XML. We don't parse the game XML until we start a new game. > > We really don't want to start a new game just to read which variants > exist, if any. > > So, it appears that we may need to refactor our initialization code a > bit, or create a new interface to loading the XML properties. In any case, part of the code in Options should move to GameUIManager. But that can be done after we have found a good concept. Let's do that first. > I think we might be able to get away with just creating an array of > ComponentManagers, and read all of the Game.xmls on startup. > This should > give us all of the information we need to present the inital game > information and game variant options. Yes, I was thinking along the same lines. My suggestion is to split Game.xml into a smaller Game.xml that only has the startup options, and a Components.xml that contains all the rest. Only Game.xml is needed to find out about variants and such. > 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. > Then, when the New Game button is clicked, we can just choose > the proper > ComponentManager from the array, and discard the rest. In my proposal: then start loading Components.xml. Erik. |