2010/6/8 Peter Hunsberger <peter.hunsberger@xxxxxxxxx>
On Tue, Jun 8, 2010 at 1:26 PM, uaca man <uacaman@xxxxxxxxx> wrote:Then each thing the building interacts with has it's own unique set of
>> 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!
states. The only ones you need worry about are the ones a _user_ is
actually interacting with at any given point.
I guess that there is no easy solution, will try the first bet and calculate the past every user request.
>
> Looks like we are going to cut off a few options of the game.
> ps: do i top post or bottom post here?
>
--
Peter Hunsberger
