Re: Queues Problem

2010/6/8 Peter Hunsberger <peter(dot)hunsberger(at)gmail(dot)com>

> On Tue, Jun 8, 2010 at 1:26 PM, uaca man <uacaman(at)gmail(dot)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
>