2010/6/8 Peter Hunsberger <peter.hunsber...@gmail.com> > On Tue, Jun 8, 2010 at 1:26 PM, uaca man <uaca...@gmail.com> wrote: > >> 2) Think of the front end as changing states as the user interacts > >> with it, then figure out what queries need to be made to correspond to > >> the changes in state. For example, it is unlikely the user needs the > >> amount of "gold" updated every 5 seconds. Rather, they need to know > >> how much they have on hand when they go to use it. At that point, you > >> query for the old balance, find the last updated time, how many > >> buildings have been completed since then and for how long and figure > >> out what the new gold balance is. Update the new balance at that > >> point (with a timestamp), and the front end goes on it's merry way... > > > > That is exactly what we are doing for the most part and was our first bet > > with the buildings, however since building can affect pretty much > anything, > > anywhere on the game changing states as the user interacts is getting > beyond > > comprehension of a human mind(al least for my mind) and that was when I > had > > the super idea, lest put the queue on the crontab! > > Then each thing the building interacts with has it's own unique set of > states. The only ones you need worry about are the ones a _user_ is > actually interacting with at any given point. > > > > > Looks like we are going to cut off a few options of the game. > > ps: do i top post or bottom post here? > > > > I guess that there is no easy solution, will try the first bet and > calculate the past every user request. >
> -- > Peter Hunsberger >
