Re: Queues Problem

On 6/8/2010 1:26 PM, uaca man 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!
>
> Looks like we are going to cut off a few options of the game.
>
> ps: do i top post or bottom post here?
>
>
>
> 2010/6/8 Peter Hunsberger <peter(dot)hunsberger(at)gmail(dot)com
> <mailto:peter(dot)hunsberger(at)gmail(dot)com>>
>
> On Tue, Jun 8, 2010 at 1:00 PM, uaca man <uacaman(at)gmail(dot)com
> <mailto:uacaman(at)gmail(dot)com>> wrote:
> > This would work except for one thing, the building may affect another
> > buildings, Consider this:
> >
> > the user starts one construction that will finish in 10 minutes
> and the
> > building will give a bonus of +5 gold each seconds for the user.
> This has to
> > be available in the seconds that the build is done and not one
> hour late
> > because the user will lose the bonus for one hour.
> >
>
> Sounds like you need to take a big step back and figure out what
> overall systems architecture makes sense for a real time gaming
> platform.... Couple of suggestions:
>
> 1) If you need real time events you do them where you need them: on
> the front end, where the user interaction is happening. Do not
> attempt to code gaming rules and logic into database triggers and back
> end relationships (though you might store gaming rules etc. in a
> table).
>
> 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...
>
> --
> Peter Hunsberger
>
>

bottom.

This is a much harder question than I'd first thought.

If you go with the program that runs every second, I see one problem:
what if the update takes more than a second to do?

I have an image of a spreadsheet in my mind, where there is a huge
interdependence on the cells. Have no idea what I'm talking about here,
but how about some kind of state machine? Then you can roll the state
forward (or backward). If the formula had some kind of time element
then the "cells" could be recalculated for any given point in time.

ahh, well, in any case, I really dont know. Sounds like an interesting
problem though.

-Andy