[Rails-devel] Removal of static class variables (git: 8b9df8)

[Stefan F. <ste...@we...>]

With respect to Brett wishes below I decided to not add further Managers, but 
instead added a storage possibility to the GameManager.

However I tried to make this a general storage for all kind of objects instead 
of adding two specific storages.
Due to the fact that Token stores ids as Strings ("Token_#") with indices 
starting at zero and SpecialProperties as Integer starting at one, there is 
some legacy support code which potentially could be remove when
we decide to break save file compatibility.

I have to admit that do not fully understand what Brett's concerns are: In my 
understanding it will either be a fat client/lean server (means that each 
instance has a full game model behind and the server component only broker 
messages) or a lean client/fat sever (means that the client only shows a view 
of game model on the server) and in that case the client would have none of 
the current Manager which are configured by xml.

Remark: To work with my IMAP based e-mail client the search using git ids only 
works if they are added to the subject efficiently.


On Thursday, July 21, 2011 08:09:28 am brett lentz wrote:
> Yup, that sounds like it might be necessary if one of the existing
> *Managers isn't a good fit.
> 
> I'm trying to look ahead to our dream of client/server separation
> where I expect the server will handle all the XML reading and pass
> it's authoritative information to the client. In this case, the client
> side will need to be able to instantiate objects without calling the
> ConfigureFromXML() methods in each of the *Managers.
> 
> So, if your implementation of new *Managers involves new
> ConfigureFromXML() methods, I'd like to suggest this may be the time
> to work on an alternative initialization methodology. It seems that
> GameInfoParser might be part of the solution, but I'm not certain.
> 
> Unravelling the current game init code is taking me more time than I like.
> 
> ---Brett.
>