On Tue, Jun 8, 2010 at 1:26 PM, uaca man <uacaman@xxxxxxxxx> 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? > Bottom post. -- Peter Hunsberger -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
