From: Tony C. <to...@cl...> - 2007-05-15 16:42:08
|
Quoting Lane Schwartz <dow...@gm...>: > As far as the discussion on game state and GameData goes, I agree that > keeping game state all in GameData makes sense. I'm not sure what you mean > by a factory system, and I also don't know much about serialization. > > On 5/13/07, Sean Bridges <sbr...@ya...> wrote: > > > > The way game state is represented in TripleA is quite > > lacking. Allowing game state to reside in the > > delegates, rather than forcing all state to the > > GameData was a mistake. It would be nice to push > > things like movement left this turn, what a transport > > is carrying, and others into the unit. This would > > make using this information much easier on the client, > > and would make a lot of the game logic easier. This is a good discussion, and I don't think I necessarily agree that the current way of handling game state in delegates is a bad thing. One of the nice things about keeping some aspects of game state out of the core data objects is that it is easier to hide that data from the client. For example, the TransportTracker is normally only accessible through the delegate (ignoring my recent mistake in exposing it), which is good because a client could conceivably be hacked to modify data objects and change the state of a game. We certainly need to retain the separation of data that can be seen by the client, vs. data that can only be seen by the server. I think there could certainly be a bit of cleanup, like the cleanup I've been doing with MoveDelegate/MoveValidator, but all in all I like the current design in this respect. Perhaps moving all state to Tracker objects or something would make more sense, for instance. Tony |